Add API to allow creation of widgets for customising a layer's source, allow changing xyz layer source settings in layer properties

[nyalldawson]

This adds api in the provider gui to allow a provider to create a custom widget which exposes options to customise and change the layer's source.

E.g. a file based layer provider could expose a widget for selecting a new file path, and an online one could expose widgets for changing the host, authentication, etc.

And adds two implementations of this.

1. A file picker widget for GDAL file based layers:

2. A widget for customising XYZ layer properties (it's VERY handy to allow customising the zmin/zmax on a layer by layer basis!!)

[elpaso]

@nyalldawson I'm probably missing something, isn't this in part a duplication of the source select dialogs?

And we already have the "Change data source" functionality (that relies on the browser, that in turn opens the source select dialogs).

The only difference I see in this use case is that you are not allowed to change provider, that could be implemented re-using the change data provider.

I feel that re-using (possibly enhancing) the existing source select widgets is the way to go to avoid code duplication and for a better UX.

[nyalldawson]

@elpaso there's quite a difference here between use cases. Eg take a look at the screen shot for the XYZ settings widget, and you'll see its very different to the XYZ source select widget.

Another use case I really want this for is to allow change of auth config for an existing layer. That's really tricky to do via the "change data source" > browser> data source manager approach. You're forced to edit an existing connection (or clone it), globally change its auth config, and then reselect the layer source. That's far from user friendly.

I did you with the idea of reusing the source select widget API here, but in the end rejected that idea as the source select API has zero overlap with what we need here (a set existing source, get new source string methods) and we'd just end up with a Frankensteined interface trying to handle two different use cases...

[elpaso]

@elpaso there's quite a difference here between use cases. Eg take a look at the screen shot for the XYZ settings widget, and you'll see its very different to the XYZ source select widget.

Yeah, the one I had in mind is actually the connections dialog QgsXyzConnectionDialog which is not exposed to API, I see no difference between that dialog and the one you embedded in the layer properties dialog

Are you sure you cannot abstract out the connections widgets (at least the dialog UI) to be re-usable in this context instead of creating a whole new API with duplication of functionality?

I mean, in this case GUI-wise all you have to do is to hide the connection name field.

I'm scared about maintaining another API and keep features in sync between the two GUIs.

[nyalldawson]

I guess the XYZ connection dialog could embed the subset widget from this pr, which would remove the extra UI file and some of the duplication...

But I still can't see any way to avoid the new API, the existing one just doesn't work for this functionality

[elpaso]

I guess the XYZ connection dialog could embed the subset widget from this pr, which would remove the extra UI file and some of the duplication...

This sounds like the way to go!

The important thing is to avoid to maintain two nearly identical UIs.

But I still can't see any way to avoid the new API, the existing one just doesn't work for this functionality

👍

[nyalldawson]

@elpaso done in b262350

[qgis-bot]

@nyalldawson
A documentation ticket has been opened at qgis/QGIS-Documentation#10522
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!