For algorithms with multiple parameters depending on a vector layer parameter, the code that loads the layer in the background is called repeatedly, impacting performance. A small layer cache is implemented with these changes, so the dialog only tries to load the layer once.
Also exposes this capability to modeler - so that model algorithms
can use data defined parameters within their child algorithms.
TODO:
- tests
- setting the associated vector layer
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.
- Add abstract base class for Processing widget wrappers to c++
- Add wrapper factory interface to c++
- Make QgsProcessingGuiRegistry also register widget wrapper
factories, and be responsible for creation of new c++
processing widget wrapper instances
- Start on private c++ implementation of boolean widget wrapper,
including unit tests
Fixes#19329 (https://issues.qgis.org/issues/19329)
Optional layer parameters in processing algorithms used in the graphical modeler
add an empty string as the default parameter value, which can raise an exception
during algorithm execution. This update replaces the default empty string with a
default 'Not selected' option.
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
ModelerParametersDialog and ParametersPanel have to keep list of
wrappers only. widget and label( if needed) are created through
WidgetWrapper.createLabel()
in model child algorithms
Prior to this change if you edited an algorithm in a model and
tried to enter a preset string for certain parameter types, this
string would get silently discarded on closing the dialog. E.g.
with a dissolve algorithm it was not possible to have a fixed
field name within the model to dissolve by.
This was caused by WidgetWrapper.comboValue returning the customData
for these manually entered values in the parameters combo box,
yet manually entered values never have custom data.
To work around this we only return the custom data if its
set for the selected item - otherwise we return the text unchanged.
In order to handle the "[not set]" options, a new static custom
data value of WidgetWrapper.NOT_SET_OPTION is added to that
comboValue can detect this and return the appropriate None value.
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)
