[dxf] Allow users to override the layer name to be exported to DXF

[gacarrillor]

This PR makes it possible to override the output name of individual layers exported in the DXF Export dialog.

The corresponding processing algorithm's GUI and parameter were updated accordingly.

Tests were added for:

• Output layer name precedence for the exported DXF: 1) attribute, 2) layer title, 3) overridden layer name, 4) layer name.
• Processing qgsprocessingparameterdxflayers parameter and DXF layer's widget wrapper.

Screencast App dialog

2024-03-19.18-11-48.mp4

Screencast Processing dialog

2024-03-25.10-54-11.mp4

UX hints for the users:

---

Funded by the QGIS user group Switzerland.

[qgis-bot]

@gacarrillor
This pull request has been tagged as requiring documentation.

A documentation ticket will be opened at https://github.com/qgis/QGIS-Documentation when this PR is merged.

Please update the description (not the comments) with helpful description and screenshot to help the work from documentors.
Also, any commit having [needs-doc] or [Needs Documentation] in will see its message pushed to the issue, so please be as verbose as you can.

Thank you!

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 13b0f62)

[uclaros]

Layer title (set in layer properties)

Imho, this can be expanded to direct the user to the QGIS Server tab as many users would never look there!

You can also use QgsProcessingParameterDefinition::setHelp() to set a tooltip directly on that processing tool's checkbox

[gacarrillor]

Layer title (set in layer properties)

Imho, this can be expanded to direct the user to the QGIS Server tab as many users would never look there!

Agreed. I opened this issue to get some feedback (I wasn't sure about the layer title provenance: metadata or QGIS Server). Looking at the code (and commit description), it's clear that the feature was really accounting for QGIS Server's properties.

You can also use QgsProcessingParameterDefinition::setHelp() to set a tooltip directly on that processing tool's checkbox

Cool, thanks for the tip!
(addressed in 76cad50, @uclaros)

[nyalldawson]

Imho, this can be expanded to direct the user to the QGIS Server tab as many users would never look there!

I don't think we should ever use the settings from the server tab for non server purposes. We should use the values from the layer metadata instead.

[m-kuhn]

Imho, this can be expanded to direct the user to the QGIS Server tab as many users would never look there!

I don't think we should ever use the settings from the server tab for non server purposes. We should use the values from the layer metadata instead.

While I agree in principle, this is just making the status quo explicit if I understand correctly, so changing this now would not be backwards compatible (?)

[nyalldawson]

While I agree in principle, this is just making the status quo explicit if I understand correctly, so changing this now would not be backwards compatible (?)

Couldn't we use QgsMapLayer::metadata().title() instead?

[m-kuhn]

Just switching will silently break projects which rely on the current behavior.

What we could possibly do to move to a better world is:

// TODO QGIS 4: no longer rely on server title
QString title = QgsMapLayer::metadata().title().isEmpty() ? serverTitle : QgsMapLayer::metadata().title();

And document the server title as legacy.
How does that sound for a smooth transition?

[gacarrillor]

Rebasing...
(There seems to be an unrelated test failure)

[nyalldawson]

@m-kuhn

QString title = QgsMapLayer::metadata().title().isEmpty() ? serverTitle : QgsMapLayer::metadata().title();

I'll do this in a follow up, and mark all the server related metadata properties in QgsMapLayer as deprecated after moving them to QgsMapLayerServerProperties 👍

[nyalldawson]

@m-kuhn see #57103

[m-kuhn]

@nyalldawson good move, but it doesn't affect the discussion here, does it?

@gacarrillor looks like this needs another rebase

[nyalldawson]

@m-kuhn

No, it's not directly related. It just means I withdraw my earlier reservation 👍

[gacarrillor]

Rebased, we are green!

[DelazJ]

@gacarrillor In Processing, the name the user provides is kept along with the layer name. Helpful to know what they renamed. But in the export dialog, the layer name is no longer displayed if you renamed it. Would that not be confusing? No way to provide the same rendering?

Then I am trying to guess based on the info above but I fail to get what has precedence between the naming options:

• if "attribute" is selected it is used, regardless of the other options status. OK.
• If "attribute" is not selected but I check the "use title" box and also rename the entry in the table (or the configure), which one is used? I don't think this is clear in the GUI.

[gacarrillor]

@gacarrillor In Processing, the name the user provides is kept along with the layer name. Helpful to know what they renamed. But in the export dialog, the layer name is no longer displayed if you renamed it. Would that not be confusing? No way to provide the same rendering?

@DelazJ, valid observation. Fortunately, we have the tooltip, which shows both layer name and source.

However, now that you mention it, I think it's worth exploring if we can add a reset button in the line edit, so that we can go back to the original layer name in one click.

Then I am trying to guess based on the info above but I fail to get what has precedence between the naming options:

* if "attribute" is selected it is used, regardless of the other options status. OK.

* If "attribute" is not selected but I check the "use title" box and also rename the entry in the table (or the configure), which one is used? I don't think this is clear in the GUI.

The order is as follows:

1. Attribute (if any)
2. Layer title (if any, layer metadata takes precedence over layer QGIS Server title)
3. Overridden name (if any)
4. Layer name

Perhaps we should include it in the tooltip:

"If no attribute is chosen, prefer layer title (set in layer properties) to layer overridden name and to layer name".

[DelazJ]

I think it's worth exploring if we can add a reset button in the line edit, so that we can go back to the original layer name in one click.

Could be nice indeed.

2- Layer title (if any, layer metadata takes precedence over layer QGIS Server title)
3- Overridden name (if any)

Humm I'm not really convinced by this order. If I set the name override in the alg (or GUI) just before exporting from the same dialog, I would expect it to get used. Not a title configured in another dialog, maybe some time ago. Switching the order would allow to just override a few layer names and have the others use their title (*). I'm not sure such a combination is possible in the current scenario, a title would take precedence on the "local" overridden name.

(*) does a layer necessarily have a title, either from metadata or server properties?

Perhaps we should include it in the tooltip:

We should add tooltips to all these options and adapt the tooltip to their order. Also we could expand if necessary in the docs.

[gacarrillor]

I think it's worth exploring if we can add a reset button in the line edit, so that we can go back to the original layer name in one click.

Could be nice indeed.

There you go. 👍

Switching the order would allow to just override a few layer names and have the others use their title (*). I'm not sure such a combination is possible in the current scenario, a title would take precedence on the "local" overridden name.

The current approach is flexible and is able to handle this case, i.e., if the option Use layer title as name if set is activated, but the current layer doesn't have a title, we'll pick either the overridden layer name (if any) or, at least, the layer name.

Note that the option Use layer title as name if set is unchecked by default. That is, you probably know what you're doing (e.g., you've set a title in the metadata or in QGIS Server configuration) if you check it.

(*) does a layer necessarily have a title, either from metadata or server properties?

They are both optional.

[DelazJ]

There you go. 👍

👏🏿

The current approach is flexible and is able to handle this case, i.e., if the option Use layer title as name if set is activated, but the current layer doesn't have a title, we'll pick either the overridden layer name (if any) or, at least, the layer name.

Note that the option Use layer title as name if set is unchecked by default. That is, you probably know what you're doing (e.g., you've set a title in the metadata or in QGIS Server configuration) if you check it.

Actually, my scenario is the other way. I have layers with filled metadata (or server configured). And for this specific project export, I want to use a different name for one special layer but keep using the title for the others.
Afaiu, I would have to either:

• fill the "override name" box for all the layers (reusing the title for most of them) and leave "use title" box unchecked
• or fill the "override name" for the special layer, clear its title(s) in properties and check the "use title" option

I find both options less optimal than just set the "override name" for the special layer, and check "use title" (which would apply to the not renamed layers). And all in all, what I think is that the option that is closest to where I hit "run" should have priority over the further. and in this case, "override name" is closer than layer title.

[gacarrillor]

And all in all, what I think is that the option that is closest to where I hit "run" should have priority over the further. and in this case, "override name" is closer than layer title.

I think it makes a lot of sense, thanks for the suggestion.

The order has been redefined as follows:

1. Attribute (if any)
2. Overridden name (if any)
3. Layer title (if any, layer metadata takes precedence over layer QGIS Server title)
4. Layer name

All GUI hints and unit tests have been updated accordingly.

[nirvn]

Looks good to me, let's merge this @gacarrillor . Thanks for being responsive to suggestions and opinions raised in the PR, way to go :)

[qgis-bot]

@gacarrillor
A documentation ticket has been opened at qgis/QGIS-Documentation#9028
It is your responsibility to visit this ticket and add as much detail as possible for the documentation team to correctly document this change.
Thank you!

[gacarrillor]

Looks good to me, let's merge this @gacarrillor . Thanks for being responsive to suggestions and opinions raised in the PR, way to go :)

Thanks to everyone who participated in this! 👍