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 class implements the required logic to bridge a
class which implements the QgsGeocoderInterface interface to a
QgsLocatorFilter. It allows easy creation of a locator filter
from a geocoder.
E.g.
class GoogleGeocoder(QgsGeocoderInterface):
... class which implements QgsGeocoderInterface...
my_google_geocoder = GoogleGeocoder(api_key)
my_google_locator_filter = QgsGeocoderLocatorFilter('google', 'Google Maps', 'google', my_google_geocoder, iface.mapCanvas())
iface.registerLocatorFilter(my_google_locator_filter)
Note:
There's an abstract base class QgsAbstractGeocoderLocatorFilter which
lives in core. This base class has the guts of the geocoder to filter
adapter logic, but it does NOT implement the part which actually zooms
the canvas to the geocode results (because it's in core!)
This abstract base class is in place for applications like QField,
where the GUI library and QgsMapCanvas is NOT used. Those applications
can then implement their own concrete class based on QgsAbstractGeocoderLocatorFilter
with the correct logic to zoom their interface to a region. Ultimately,
a single QgsGeocoderInterface could be usable across QGIS desktop, QField,
with almost all logic shared via the common abstract adapter class.
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
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.
of labels along line features
The new "Label Anchoring" section in the line placement settings for
labels allows users to specify whether labels should be placed
at the center, start or end of lines (or a custom percent from the
start of the line). Also allows data-defined percent along line
control!
filter mode in attribute form
(For reference: not a regression -- these buttons were originally
added for the "select by form" dialog only, and they've just never
been hooked up for use inside the attribute form itself!)
Fixes#34506
This exposes some basic temporal capabilities for vector layers:
- static time range for layer (to match raster layer possibilities), this
sets a single static time range which applies to the whole layer. ALL
features from the layer will be shown whenever the canvas time
overlaps the layer time range
- "Single field with datetime": Allows selection of a single date
or datetime field from the layer. Features will be shown whenever
this field value is within the canvas time range
- "Separate Fields for Start and End Date/Time": Allows selection
of start and end date/datetime fields from the layer. Features will
be shown whenever the time interval calculated from these fields
overlaps the canvas time range
Some known limitations/inefficiencies:
- currently only date/datetime fields can be used. This was done
to simplify the format handling and avoid the need to worry about
string fields with different datetime formats. In future we should
allow selection of string fields and allow users to enter a custom
datetime format string
- unlike the Time Manager plugin approach, the approach taken here
is to rely completely on QGIS expressions and feature requests to
do the filtering (Time Manager uses layer filter strings and attempts
to set a native SQL filter syntax so that filtering is done on the
backend). This is intentional, because it provides a unified filter
approach regardless of the provider used (i.e. we don't need to worry
about the different SQL syntaxes used natively by the different
providers). The beauty of feature request expression compilation
**should** mean that the QGIS expressions are magically turned into
native backend queries, BUUUUUUUUUUUT... because we lack QGIS expression
support for date time literals, we currently rely on the "to_datetime"
expression function and coerce everything through strings. None of
the expression compilers handle this function, so currently ALL
filtering is done on the QGIS side. We need to add functions for
optimised datetime literal creation, and then ensure that the different
compilers correctly map these literals across to the backend
filter syntax to allow all the filtering work to be done on the database
side...
So currently, performance is much worse with large layers compared
to Time Manager. But, the advantage is that we can use the native
temporal framework and have vector layers animated alongside mesh
and raster layers!
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
This new renderer draws contour lines that are calculated on the fly
from the source raster band. It is possible to set interval of contour
lines and symbol used for drawing.
In addition there is support for "index contours" - contour lines
with higher interval, typically drawn with a wider line symbol.
If we generate contour lines on input raster block with the same size as our
output raster block, the generated lines would contain too much detail.
This detail can be reduced by the "downscale" factor - this will request
lower resolution of the source raster.
