Previously we would show a warning about these, but then go ahead and try
to run the row anyway (using an empty set of parameters), resulting in
the log being filled with confusing error messages.
Instead, keep the existing warning advising about which values are
invalid, but skip the affected row and don't try to run it at all.
+ Run button is not shown anymore in the Log tab, therefore, you can only run algorithms from the Parameters tab.
+ While running an algorithm, the Parameters tab is now blocked.
+ When an algorithm execution finishes (either successfully or not), a new button Change Parameters is shown in the Log tab.
+ The Batch Algorithm Dialog is now consistent with the described behavior (before, it blocked the Parameters panel, but not the tab; and it was the only dialog blocking parameters widgets).
These changes were applied to the Algorithm Dialog and Batch Algorithm Dialog, and work on Edit in place dialogs as well.
each new algorithm execution
Avoids the situation where errors reported during an algorithm
which was overall successully executed are append to the errors
for later execution steps
Instead, record errors and report them all at the end of the batch
process. If we abort the remaining batch steps when encountering any
error, this blocks a useful use of the batch mode and prevents users
from running a batch process over a large number of input files, some
of which may be invalid.
Include the input parameter values in the report, otherwise the
results are just a meaningless list of values which can't be
associated with any particular set of inputs
Also correctly handle boolean and other output types
In processing, if an algorithm has a boolean as an output, it cannot be defined as boolean but as a number.
To be more precise in algorithms description, the commit add QgsProcessingOutputBoolean.
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)
Allows algorithms to pre-processes a set of parameters, allowing the
algorithm to clean their values.
This method is automatically called after users enter parameters, e.g.
via the algorithm dialog. This method should NOT be called manually
by algorithms.
By always trying to load all layers, we severely limit the usefulness
of batch processing. E.g. try clipping 200 layers - and then
get ready to punch something as you wait for all the results to load.
This change avoids holding onto resources and layers from earlier iterations,
and allows batch processing of many more items then is possible
if we hold on to these layers
The previous naming was too easily confused with processing outputs.
Rename them to QgsProcessingParameterFileDestination, etc... to
make it clearer what they are used for.
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...
