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.
The aim of this work is to be able to provide custom subset string editor
GUI according to the layer. Typically, so that a WFS layer uses the same
editor than in its select source, or that a plugin can provide a custom
editor.
* Add QgsSubsetStringEditorInterface: abstract interface to define a dialog
that can edit a subset string
* Make QgsQueryBuilder implement QgsSubsetStringEditorInterface
* Add QgsSubsetStringEditorProvider: interface for thos who want to provide
a dialog to edit a subset string.
* Add QgsSubsetStringEditorProviderRegistry: keeps a list of subset string
editor providers. Transposed from QgsDataItemGuiProviderRegistry
* Add QgsGui::subsetStringEditorProviderRegistry()
This signal is emitted whenever the application options have been changed.
This signal is a "blanket" signal, and will be emitted whenever the options dialog
has been accepted regardless of whether or not individual settings are changed.
It is designed as a "last resort" fallback only, allowing widgets to respond
to possible settings changes.
The previous approach was severely broken, because the default
CRS for new projects setting was ignored as soon as a layer
was added to the project.
Instead, refine the setting to add options
- "Use CRS from first layer added": same as previous behavior,
the project CRS is set to match the first layer added to a new
project
- "Use a default CRS": CRS for a new project is set to a preset
default CRS, and is left unchanged when adding layers to the
project
Also update qgis_global_settings.ini to reflect these changes.
Fixes#27516
If they are deleted, any other python wrappers which have been parented to these singletons are deleted too.
One of the most common issues with this is, that subclasses of registry items are deleted and lost.
These providers will be used to control how the browser data items
behave within GUI, and to allow separation of GUI related
properties of browser items from the core code.
A new registry QgsDataItemGuiProviderRegistry has been created
(modeled off QgsDataItemProviderRegistry), with an application
wide instance available from QgsGui::instance()->dataItemGuiProviderRegistry()
With implementation in app. This allows GUI library classes to
re-use standard dialogs which are created in app. The initial
use-case is to allow the GUI library symbol list widget to
focus/open an existing Style Manager dialog (created in app),
instead of opening a new modal style manager dialog.
Side benefit - moves some code out of the monolithic qgisapp.cpp
file.
