When designing a model, users typically will need to run the model
many times as they tweak its structure.
This change causes the parameters used when running the model from
the designer to be remembered and saved into the model, so that
each time you run the model from the designer you don't have to
re-set all the input parameter values to the desired test ones.
Makes iterative model design SO much easier!
Sponsored by Alta Ehf
Only minimal shells of objects are left in Python now, the bare minimum
required because they call objects which depend on Python compatibility
for deprecated API calls...
to handle creation of parameter definition widgets
Previously, these configuration widgets were all hardcoded into the Python modeler
dialog. This prevented 3rd party, plugin provided, parameters from ever being full
first class citizens in QGIS, as there was no way to allow their use as inputs to
user created models to be customised.
Now, the registry is responsible for creating the configuration widget, allowing
for 3rd party parameter types to provide their own customised configuration
widgets.
Refs #26493
And add a Processing setting to allow these to be shown. When shown, they
are highlighted in red with a tooltip explaining that the algorithm
has known issues
This adds a new "Model Variables" dock panel to the model editor, allowing
users to create and set custom expression variables for use in the model.
These variables are available anywhere expressions are (correctly) evaluated
within the model, so can be used as input parameter values for child
algorithms, within data-defined dynamic parameters, etc.
The use case here is for models which use a constant value throughout
multiple steps within the model (e.g. @target_resolution: a target
raster resolution, @max_simplification: a simplification value for
input features coming from different sources, etc), allowing users
one single place to define and edit these constant values (instead
of hunting down and setting them in multiple places throughout the model).
These variables are stored within the model itself, and are not exposed
outside of the model designer dialog.
Brings back QGIS 2.18's ability to directly convert a Processing model
to an equivalent Processing Python script algorithm, correctly
updated and working in the 3.x API.
Available from the model dialog, and from the right-click context
menu on an existing model.
Sponsored by Solspec
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 supported by the toolbox now, so relax the requirement
that all models have a compulsory group name. If no group is set,
the model is shown directly under the Models node in the toolbox.
Also switch a warning from message box to message bar
Because there's some deep underlying issue which causes the dock
layouts to get corrupted in certain circumstances, avoid the
issue entirely by moving construction of the docks out of
the .ui file and instead do it all manually via Python code.
Fixes#16428, #19068
