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.
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.
These allow plugins to extend the "Open Project" dialog by adding in support
for new file filters, which appear in the formats drop down list alongside
the existing "QGS Projects" entry.
Custom project open handlers then get first chance at loading project files.
This allows plugins to extend QGIS support by adding integrated support for
opening projects from non QGS/QGZ formats, e.g. allowing users to open
ArcGIS MXD documents or MapInfo WOR Workspaces direct from the project open
dialog.
These non-native projects are also added to the recent projects list and
welcome screen, giving them a truly first-class experience within QGIS.
Sponsored by SLYR
"development/debugging" tools
These tools appear in a new Development/Debugging Tools dock,
and provide a unified handling and place for these tools in the
UI.
The intention here is that specialised development/debugging tools
will be moved to this common interface, e.g.
- network logger
- first aid style Python local variables inspector
- startup time debugging tools
- layer load and rendering time debugging tools
... ?
Returns a reference to the main window "Plugin Help" sub-menu.
Plugins are encouraged to insert help and about actions in this submenu instead of creating
a submenu under the pluginMenu() which solely contains Plugin Help or About actions.
For example, a plugin which only implements a processing provider should not
create additional ui menus just to link to the plugin help pages. Rather, they
should use this new submenu (available under the Help menu) to insert
their help links.
For the c++ api dox this expands to "\c nullptr" (the
\c directive indicates a code literal value), and for sipify/Python
it expands to ``None`` (`` is sphinx annotation for literal values)
Makes for nicer dox for both c++ and Python!
layout designer interface API
This commit adds more methods to the public, stable API for the layout
designer dialog, allowing plugins and scripts greater flexibility
in extending and hooking into the layout designer.
New API includes:
- access to the main menus shown in the dialog, allowing custom actions
to be added to the dialog
- access to the dialog's toolbars
- methods for adding (and removing) additional dock widgets to the designer
- the method used to show/hide rulers in the designer
