populating batch processing dialog
This option adds news rows using the values from an expression
which returns an array. (As opposed to "Calculate by Expression",
which works only on existing rows).
The intended use case is to allow populating the batch dialog
using complex numeric series, e.g. those created by the "generate_series"
expression function.
For example, adding rows for a batch buffer using the expression
generate_series(100, 1000, 50)
(results in new rows with values 100, 150, 200, .... 1000)
This new option is available under the Autofill menu for a column. Selecting it allows users
to create a new QGIS expression to use to update the value inside that column. Existing
parameter values (including those from other columns) are available for use inside
the expression via @variables.
E.g. this allows setting output file names to complex expressions like
'/home/me/stuff/buffer_' || left(@input, 30) || '_' || @distance || '.shp'
to an explicit widget in the table
The double-click-header action is very hidden, and many users will
not stumble upon this. By moving it to an explicit "Autofill" widget at the
top of the table, we make this important action much more user
discoverable.
It also gives the possibility of other, parameter specific, autofill
actions (e.g. fill by expression, fill by file pattern)
- 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
While no-one is likely to use the batch dialog to run a single
operation, it's a bit unexpected to see two empty rows, which
can't be removed, when first opening this dialog
This somewhat changes the meaning of outputs from processing 2.x.
In 2.x processing outputs were used both as a method of specifying
inputs to algorithms (file paths to destination layers created
by the algorithm) AND pure outputs (such as statistics calculated
by the algorithm).
This is now split. The old input-type-outputs (destination layers)
are now input parameters (since the parameter value IS an input to the
algorithm). To differentiate them from parameters indicating pure
input layers a new "isDestination()" method was added to
QgsProcessingParameterDefinition.
Output definitions are now purely indications of values CREATED
by the algorithms. Suitable candidates are the existing calculated
stats and actual file path/URI of any layers created by the algorithm.
Moving forward we should ensure all algorithms output as much
useful information as possible - e.g. number of features processed,
number of skipped features, count null geometries encountered, etc...
