and logic for activating a custom map tool and ensuring it can
only be enabled in the right circumstances to QGIS app
If a plugin has to do this, it's a nightmare of code and hacks (partly
because of the number of changing circumstances it needs to respond
to, and partly because a lot of the useful functions available
for handling this behavior is locked away in private methods
in qgisapp.cpp)
So instead make an abstract base class for map tool handlers and
an iface method for register/unregistering them.
From the dox:
An abstract base class for map tool handlers which automatically handle all the necessary
logic for toggling the map tool and enabling/disabling the associated action
when the QGIS application is in a state permissible for the tool.
Creating these handlers avoids a lot of complex setup code and manual connections
which are otherwise necessary to ensure that a map tool is correctly activated and
deactivated when the state of the QGIS application changes (e.g. when the active
layer is changed, when edit modes are toggled, when other map tools are switched
to, etc).
- ### Example
\code{.py}
class MyMapTool(QgsMapTool):
...
class MyMapToolHandler(QgsAbstractMapToolHandler):
def __init__(self, tool, action):
super().__init__(tool, action)
def isCompatibleWithLayer(self, layer, context):
# this tool can only be activated when an editable vector layer is selected
return isinstance(layer, QgsVectorLayer) and layer.isEditable()
my_tool = MyMapTool()
my_action = QAction('My Map Tool')
my_handler = MyMapToolHandler(my_tool, my_action)
iface.registerMapToolHandler(my_handler)
\endcode
Any actions added by plugins for toggling a map tool should also
be added to this action group so that they behave identically
to the native, in-built map tool actions.
Just like all other map layer types, meshes CAN have metadata set,
so expose this via a metadata tab in their layer properties window
just like any other layer type.
the QGIS application from exiting
This interface allows plugins to implement custom logic to determine whether it is safe
for the application to exit, e.g. by checking whether the plugin or script has any
unsaved changes which should be saved or discarded before allowing QGIS to exit.
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.
to new "Code Editor" tab in options dialog
These settings apply to more than just the Python console editors -
rather they apply to all code editors across QGIS (including expression
editors)
Remove a bunch of duplicate default color definitions, and ensure
that all subclasses correctly respect any user defined color overrides,
yet that we still default to following the application theme's matching
color schemes.
