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!)
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.
