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/
When an algorithm has a distance parameter in meters/feet/etc (i.e.
non-geographic distances), show a combo box allowing choice of
unit type.
(We don't (and should never) expose this for distances in degrees --
it's up to users in this situation to choose a suitable local
projection and reproject their data to match. Refs: a recent
talk by @volaya)
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
When running algorithms through the toolbox, which have dynamic
numeric parameters, add a data defined property override button
next to the widget so that users can set the overrides for these
parameters.
Previously this was available only in the backend, but not
exposed anywhere in the GUI.
Note that currently no algorithms support dynamic parameters,
so don't expect to see this everywhere. It's also only available
in toolbox/batch processing modes, not in models.
Without this change optional numeric parameters have no way to
be cleared in the GUI - they are always forced to have a value
Fixes#17471 - but I've noticed that many optional numeric
GRASS parameters have a non-null default value. These may
need to be investigated and manually changed to None defaults
in the description files.
Since these expressions were only evaluated immediately, it led to
confusing behavior for users who were expecting that the expression
would be applied per-feature.
Given that expressions can be directly entered into spin boxes, we already
have a way of users evaluating simple calculations for numeric
parameters at least.
I don't think there's a strong enough use case for needing to
calculate string results to leave the confusing expression builder
option in place.
This should be re-evaluated when we add UI support for dynamic
parameters (which are already supported in the backend), where
expressions are evaluated per-feature.
Fixes#17267
Contains variables for model parameters, algorithm results for
other child algorithms which are not dependent on the
algorithm.
Allows removal of final pieces of ModelerAlgorithm code
This commit restores some pre 3.0 processing behaviour for number inputs.
Now, if a number input is required outside of modeller than a spin box
will be shown instead of a free text input.
Clicking the expression builder button results in an expression
which is evaluated immediately to avoid users expecting that
the expression will be evaluated per feature.
