This allows encapsulation of properties relating to the context
of a search, such as a target map extent. Locator filters could
use this to prioritise results close to the current canvas extent.
This adds a new "locator" bar to the QGIS status bar. If you're not
familiar with QtCreator's locator, it's a quick search bar
(activated by Ctrl+K) which displays matching search results
from any number of registered search filters.
Search filters are subclassed from QgsLocatorFilter, and
added to the app's locator via iface.registerLocatorFilter(...)
Searching is handled using threads, so that results always
become available as quickly as possible, regardless of whether
any slow search filters may be installed. They also appear
as soon as each result is encountered by each filter, which means
that e.g. a file search filter will show results one by one
as the file tree is scanned. This ensures that the UI is always
responsive even if a very slow search filter is present (e.g.
one which uses an online service).
This framework is designed to be extended by plugins, such as
OSM nominatim searches, direct database searching (i.e. Discovery
plugin), layer catalog searches, etc...
Historically the configuration used to be stored in layer's custom properties, but that does not scale
beyond simple rendering and so rule-based labeling introduced storage of configuration natively in XML elements.
That left us with two different ways of reading/writing labeling configurations. This work makes all configuration
to use native XML elements.
To keep compatibility of 2.x projects, reading of configuration from custom properties is preserved.
This commit also adds Python APIs for direct manipulation of labeling configuration through vector layer's
setLabeling() and labeling() calls.
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.
A QgsNative base class is added, that offers default implementations for
a platform interface. These methods can be overridded for the current
platform at compile time to allow specialized handling for integration
with the current system.
This is necessary in order to be able to correctly translate between absolute and relative paths
deeper in the code - e.g. paths to SVG files used in marker or fill symbols.
Until now, relative paths were translated to absolute paths on the fly.
This is now changed - paths to files should be always absolute within QGIS objects - and paths
only get turned into relative when saving projects. When loading a project, relative paths
are translated to absolute paths immediately.
This should lower the overall confusion about relative/absolute paths within QGIS, and also
allow having different base directories for relative paths (e.g. QML or QPT files may use relative paths
to their directory - rather than to the project directory)
Since the majority of users of this class will be exporting
an existing map layer to a data provider, the QgsVectorLayerImport
name is misleading and suggests that this class is designed
just to bring layers "into" QGIS.
Explicitly naming the class "Exporter" should help API users
discover this class.
Also cleanup API and improve docs
This commit adds the virtual method for running processing algs
to the base c++ class, and adds the initial framework
for c++ algorithm parameters.
When running an algorithm, a QVariantMap is passed
as the algorithm parameters. The high level API provided
by QgsProcessingParameters should be used to retrieve
strings/layers/doubles/etc from this QVariantMap.
This allows advanced use cases, such as passing QgsProperty
with the QVariantMap for "dynamic" parameters, where the
value should be evaluated for every feature processed.
E.g. if the buffer algorithm uses a dynamic property for distance,
then the distance could be bound to either a field value or
to a custom expression. This gets evaluated before buffering
each feature to allow for advanced variable buffering.
Support for dynamic parameters will be "opt in", and non default.
So algorithms will need to specifically add support for
dynamic properties as required.
