this has been done automatically with the following comand line
./scripts/3to4/3to4.py --only-qgis3-compatible-changes ./python/plugins/
./scripts/3to4/3to4.py --only-qgis3-compatible-changes ./tests/src/python/
Specifically, this fixes two issues
1. If a user edits a dark green output block in a model and changes the
name of the output, that new name was always discarded and the only
way to change it was by editing the algorithm it was attached to
2. If an output was renamed through the algorithm properties dialog,
then any properties previously associated with that output (like
comments, coloring, placement, default value, mandatory flag)
would get reset back to their default settings
This allows defered setting of parameter values, e.g. if you add an algorithm, fill in
half the parameter values, then realise you need to add a new input to the model, you
don't have to lose all your filled in values...
This allows a range of new possibilities, including:
- models with static outputs for child algorithms, e.g. always saving
a child algorithm's output to a geopackage or postgres layer
- models with expression based output values for child algorithms, e.g.
generating an automatic file name based on today's date and saving
outputs to that file
This allows users to create comments attached to model components (inputs,
algorithms or outputs). Comments are shown linked to the associated component,
and can be freely moved around the model.
model designer, prefer to show the user's defined name for that output
instead of the generic one
Makes it easier to associate inputs with the correct outputs when
creating models
data defined buttons for model child algorithms
The context was not previously exposed, so users would not have
been aware that they can utilise all the variables and functions
available to parameters within child algorithms.
A new widget which handles parameter values for child algorithms
within a model. Instead of the previous approach of requiring
individual widget wrappers to handle creation of a suitable
model widget, we do all this automatically for them.
This widget uses a stacked widget with a toolbutton to select
the parameter's source, instead of the previous combo box approach
(which didn't scale well for large models). I.e. users select
first whether the value is taken from a static value, a
model input, or an output from a different child algorithm. The
widget then changes appearance and behavior based on this
choice.
Additionally, a new option is present for all parameters
of using a "precalculated expression". This expression is
evaluated once before the child algorithm is executed
and used during the execution of that algorithm.
ModelerParametersDialog and ParametersPanel have to keep list of
wrappers only. widget and label( if needed) are created through
WidgetWrapper.createLabel()
