And make sipify handle this nicely. This means that all our non-flag
style enums correctly map across to IntFlag python enums on Qt 6,
fixing issues with negative enum values for these and providing
a better match for the original c++ enum.
This is the base API interface classes for creation of custom
2d or 3d map controllers, and registering them in a common
QgsInputControllerManager singleton class.
Accessible via QgsGui::recentStyleHandler(), this is intended as
a place to store recently used style items (e.g. symbols).
Initially it's used just for annotation items so that newly
created annotation items are automatically set to the same style
as the most recently modified item of the same type (e.g. so
that users drawing many point annotations don't need to keep
setting it back to the same appearance)! But the api is kept
flexible for additional uses in future... (eg layout items)
This registry is attached to QgsGui and handles registration of
functions which create widgets for modifying QgsAnnotationItems
Modeled heavily off the print layout API
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.
Usage:
- QgsGui::instance()->enableAutoGeometryRestore( this ); just
after setupUi in your widgets to enable.
- Remove any calls to saveGeometry() and restoreGeometry() in your
widgets.
Instead of relying on forward declared c++ classes from
gui in QgsLayoutItemRegistry, instead create a
QgsLayoutItemGuiRegistry which handles registration
of all the GUI specific behavior relating to layout items.
Remove all GUI related code from QgsLayoutItemRegistry.
This creates a cleaner split between core/gui code, and
given that there'll be a lot of gui specific behavior
which needs to be handled by a registry it makes sense
to keep this isolated in gui.
It also plays nicer with the sip bindings, which can't
handle forward declared gui classes in core.
This allows gui widgets to utilise native platform interfaces.
Additionally attaching the instance to QgsGui allows QgsNative
to become a QObject in future if required and for use
of signals/slots in the native interfaces.
