layer, so that these renderers are always drawn either above or
below the normal layer renderer
This allows programatic creation of extra styling for a vector layer,
e.g. to overlay custom markers or outlines on features (such as
highlighting "good" or "bad" features), without messing with
any user-created symbology for the layer.
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.
This has MANY benefits:
- Shows the merged feature service/map service view we use in browser
- Avoids the HUGE main thread ui hang when connecting to servers with
many layers (could be 20 mins+ for some services)
- Avoids bombing out and showing incomplete lists when a server reports
an error when connecting to any of the services it advertises (happens
often)
For same reason as we do in Processing registry:
(from the comments included in this commit)
"
While it seems like /Factory/ would be the correct annotations here, that's not
the case.
As per Phil Thomson's advice on https://www.riverbankcomputing.com/pipermail/pyqt/2017-July/039450.html:
"
/Factory/ is used when the instance returned is guaranteed to be new to Python.
In this case it isn't because it has already been seen when being returned by QgsProcessingAlgorithm::createInstance()
(However for a different sub-class implemented in C++ then it would be the first time it was seen
by Python so the /Factory/ on create() would be correct.)
You might try using /TransferBack/ on create() instead - that might be the best compromise.
"
This is mainly useful for Python, this way we can probably
avoid calling fields() and all related cost when all we need
is colum names for display.
I'm not very happy with the method name and I would probably just
drop the old signature for executeSql and replace it with the new
one, unfortunately is public API.
But if everybody is happy we could consider an API break.
