execution on generated layers after the algorithm (or parent
model) completes
This commit adds an interface for layer post-processing handlers
for execution following a processing algorithm operation.
Post-processing of a layer will ONLY occur if that layer is set
to be loaded into a QGIS project on algorithm completion.
Algorithms that wish to set post-processing steps for generated
layers should implement this interface in a separate class
(NOT the algorithm class itself!) and implement a method
to handle the layer post-processing.
This method always runs in the main thread and can be used to
setup renderers, editor widgets, metadata, etc for the given layer.
Fixes#17961
Instead of returning a single QgsFeature from processFeature, we now
return a list of features.
This allows feature based algorithms which return multiple features
per input feature, e.g. "explode" type algorithms which split a
single input feature into multiple output features.
to a destination
Before we silently ignored these - now algorithms will automatically
push errors to the log if a feature cannot be written to a sink (no
changes to algorithms or special handling required)
This was a missing capability in the processing API - while algorithms
could declare multiple layer input parameters, there was no corresponding
multi-layer output. This meant that algorithms (such as Package Layers,
Vector Split) which create a set of layers which cannot be determined
in advance had no way to pass these generated layers on for further model
processing steps.
It's also useful for algorithms which operate on a specified folder,
processing all layers found there, and allowing these generated
outputs to be utilised in other model steps (e.g. packaging
all of them, merging them, etc)
their unique id()
This is used when generating the QgsHelp url for algorithms
attached to the providers.
Implement helpId overrides for the native and 3d providers so
that they return 'qgis' helpIds, meaning that all QGIS processing
algorithm documentation can be kept within the same url path
regardless of which QGIS provider library it sits within.
This also allows us to freely move algorithms from the Python
'qgis' provider to c++ 'native' provider in future releases
without breaking the help URLs.
Fixes#17231
But always prefer case-exact matches for parameter names. Turns
out the grass provider requires use of parameters with the same
name but different case, so we need to be able to handle this.
Since the underlying issues with the Python bindings are now fixed,
in most cases we can safely default to allowing an algorithm to
run in a background thread!!
So now we make this the default, and require individual algorithms
which are NOT thread safe to declare this. This includes algorithms
which directly manipulate the current project or layers (such as
setting layer styles), alter the selections in layers, or which
rely on 3rd party libraries (for now, SAGA and GRASS algorithms
are marked as not thread safe... TODO - someone more familiar with
these libraries can investigate and remove the flag if appropriate).
Also models are marked as non-thread safe. TODO: only flag an
individual model as thread-unsafe if any of its child algorithms
report this flag.
And make this support opt-out, since the vast majority of providers
are based on QGIS API and don't have external dependencies which would
restrict use of memory layers/etc.
Plus, I'd rather see non-compliant providers expose this support when
they can't use non-file-based-outputs (and make this the bug which
needs fixing) then have to rely on plugin providers to discover and
explicitly expose this support.
options should be available for certain model outputs and script
algorithm outputs
We do this by swapping the test for non-file based output support
from checking only the algorithm's provider to instead checking
on a parameter-by-parameter basis.
This is done in order to support models. For models, depending
on what child algorithm a model output is based off, an individual
model may or may not have support for non-file based outputs. E.g
a model may generate outputs from a native qgis alg (supporting
these outputs) AND an output from a GDAL alg (with no support
for these outputs). In this case we need to enable or disable
the ui controls for non-file based outputs on an individual
output basis.
For scripts (for now) we blindly just say all outputs support
non-file based formats. This is going to be the case most of
the time, since scripts will usually be written using PyQGIS
API. For the exceptions (e.g. scripts which call other algs
like GDAL algs) we probably should add some way for the script
to indicate whether an individual output supports this, but
for now we just say they all do.
Fixes#17949
Run clang-tidy modernize-use-override to remove all the redundant
virtual keywords from overridden methods, and add some missing
overrides.
Another benefit is that this has also added the overrides
on destructors, which will cause a build failure if a base
class is missing a virtual destructor.
