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.
This is a subclass of QgsProcessingParameterNumber, but specifically
for numeric parameters which represent distances. It is linked
to a parent parameter, from which the distance unit will
be determined, and is shown using a dedicated distance widget
within the processing parameters panel. This widget shows
the distance unit.
This avoids the confusion when running algorithms which
use distances where the unit depends on a layer or CRS parameter -
e.g. the distance parameter in the buffer algorithm gives
the distance in layer units... so now we can show those units
directly within the dialog. Hopefully this leads to less
user confusion and accidental "1000 degree buffers"!
Additionally - if the unit is in degrees, a small warning
icon is shown next to the parameter. The tooltip for this
icon advises users to reproject data into a suitable
projected local coordinate system.
Initially implemented for the native buffer and single
sided buffer algorithm only - but more will be added.
Fixes#16290
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)
