provider loading until after ALL plugins have been loaded
This avoids the model provider from refreshing all the model
algorithms multiple times, once for each non-default plugin installed
which implements a processing provider.
After running algorithm, the processing plugin take the layer from result to provide map layer instead of string.
In the case of QgsProcessingOutputMultipleLayers, the instance check is not done on the layer but on an array.
This provider has not been maintained and does not work with
newer SAGA versions. Users are encouraged to use the 3rd-party
"Processing Saga NextGen" plugin instead.
to Processing. These are useful for 3rd party tools as outputs can be
automatically loaded on algorithm completion.
It is an API change not visible for users.
when a script calls Processing.initialize() if they are not
already loaded
This means the following ugly code can be avoided:
Processing.initialize()
QgsApplication.processingRegistry().addProvider(QgsNativeAlgorithms(QgsApplication.processingRegistry()))
QgsApplication.processingRegistry().addProvider(Qgs3DAlgorithms(QgsApplication.processingRegistry()))
and instead the call to Processing.initialize() is sufficient to load
ALL providers
Fixes#41310
don't raise a generic "something went wrong" exception but instead
ensure that the original exception with the proper error message
is raised for catching in Python instead
Allows processing models to be stored inside QGIS project files,
so that opening the project makes that model available.
Some models are so intrinsically linked to the logic inside
a particular project that they have no meaning (or are totally
broken) outside of that project (e.g. models which rely
on the presence of particular map layers, relations, etc)
This change allows these models to be stored inside that project,
avoid cluttering up the "global" model provider with models
which make no sense, and making it easier to distribute a single
project with these models included.
Models are stored inside projects by clicking the new "embed
in project" button in the modeler dialog toolbar. Models can be
removed from a project from the model's right click menu in the
toolbox.
Relying on the iface messagebar feedback as a fallback is not
safe for standalone scripts. If callers want to use a message
bar feedback they should specify this feedback object specifically
when calling processing.run
Processing module should only register it's own basic providers.
Note that when reloading a plugin, subclasses of ProcessingProvider remains and new ones are added,
so in such cases QgsProcessingProvider.__subclasses__() return same provider class many times.
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)
initAlgorithm() method
This allows 2 benefits:
- algorithms can be subclassed and have subclasses add additional
parameters/outputs to the algorithm. With the previous approach
of declaring parameters/outputs in the constructor, it's not
possible to call virtual methods to add additional parameters/
outputs (since you can't call virtual methods from a constructor).
- initAlgorithm takes a variant map argument, allowing the algorithm
to dynamically adjust its declared parameters and outputs according
to this configuration map. This potentially allows model algorithms which
can be configured to have variable numbers of parameters and
outputs at run time. E.g. a "router" algorithm which directs
features to one of any number of output sinks depending on some
user configured criteria.
converted to QgsMapLayer objects with the ownership transferred
to the Python caller
This should make it super-easy for PyQGIS scripts to run processing
algorithms and immediately utilise the results, even if they
are memory layers. They call processing.run(), and get a dict of
results back which includes those layers ready for adding to the
current project or doing some other processing or operations
with, and if they don't transfer to ownership off then these
layers will be correctly garbaged collected by Python.
