No user visible changes, but we gain the flexibility for better
history storage, including the ability to store the outputs
calculated by the algorithm execution...!
current settings as JSON and paste json settings from clipboard
The utility of this is two fold:
1. It provides a way for users to copy the settings defined in the
dialog in a text format, so they can store these easily and then
restore later by pasting the value
2. It provides an easy way for users to copy the settings into
the json format consumed by qgis_process (following
https://github.com/qgis/QGIS/pull/46497), so that it is easy
for users to see the expected format even for complex parameters
(like tin interpolation parameters)
keyword in Python, so this value was previously inaccessible to PyQGIS
scripts
Also change all references to Qgis::MessageLevel values to their
fully qualified names, to ease a future transition to an enum
class (when sip bugs are fixed)
Fixes#42996
ensure that the correct expression context is set for the widget
Otherwise we don't see any of the available variables ready for
use in the calculation.
We need to do this manually after creating the widget, because the
context generator isn't set till after the widget is created, and
this particular widget configuration doesn't fetch the expression
context on demand.
add an explicit log level getter/setter to QgsProcessingContext which
algorithms can use to determine an appropriate level of feedback
to push to users.
Initially the verbose log only triggers the full verbose output
of model executions (which is also used when running models through
the model designer), but the intention is that more algorithms
will fine tune their output based on the logging level.
qgis_process also gains a new --verbose switch to enable verbose
log output.
This change "dims" the results from the SAGA provider when a search
is made in the toolbox, to visually push users towards picking alternative
algorithms instead.
The Processing implementation of SAGA algorithms are a constant source
of critical bugs for users, causing incorrect analysis results. There's
zero community interest in actively maintaining this provider, so we
need to take steps to push users to stop picking these algorithms
wherever alternative (QGIS/GRASS/GDAL based) equivalents exist.
And for 4.0, seriously re-consider dropping this provider from the
out of the box install. We are causing more harm then good by offering
it to users.
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
These are a visual guide, allowing designers to create logical groups
of algorithms relating to a single task ("eg 'Prepare data')
The title and color of the group boxes can be customized
show the obtained values for all child algorithm outputs within the designer
canvas
This gives users better tools for debugging models - they can see exactly
what values were output by the child algorithms and flowed into other
parts of their model
