Instead of forcing all steps in the batch processing dialog to execute
in the main thread, we now run each step as a separate task whenever
possible. This keeps the UI nice and responsive, and permits
responsive cancelation and progress reporting.
Individual steps are still run sequentially, not in parallel (yet!)
also update the internal name of that parameter and all child algorithms
in the model accordingly
Before we just "faked" this by changing the parameter's description
only, but that meant that the old name was permenantly stuck and
had to be used in qgis_process or when calling the model via
python.
to Processing. These are useful for 3rd party tools as outputs can be
automatically loaded on algorithm completion.
It is an API change not visible for users.
with preset choices in processing GUI
In some circumstances it is desirable to restrict the values available
when a user is asked to enter a string parameter to a list of predetermined
"valid" values, yet these values will vary installation by installation
(e.g. a "printer name" parameter, where you want users to pick from
printers installed on the system, but since the printer names will
vary install to install an enum parameter is not a valid choice)
This can now be done by setting the widget wrapper metadata
"value_hints" option, as demonstrated below. (While this provides a mechanism
for guiding users to select from valid string values when running a Processing
algorithm through the GUI, it does not place any limits on the string values
accepted via PyQGIS codes or when running the algorithm via other non-gui
means. Algorithms should gracefully handle other values accordingly.)
param = QgsProcessingParameterString( 'PRINTER_NAME', 'Printer name')
# show only printers which are available on the current system as options
# for the string input.
param.setMetadata( {'widget_wrapper':
{ 'value_hints': ['Inkjet printer', 'Laser printer'] }
})
helpful comments next to all static enum parameter values used
in child algorithms with the corresponding text.
I.e. instead of
alg_params = {
'END_CAP_STYLE': 2,
}
we now export
alg_params = {
'END_CAP_STYLE': 2, # Flat
}
Much more readable!
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.
