This was a missing capability in the processing API - while algorithms
could declare multiple layer input parameters, there was no corresponding
multi-layer output. This meant that algorithms (such as Package Layers,
Vector Split) which create a set of layers which cannot be determined
in advance had no way to pass these generated layers on for further model
processing steps.
It's also useful for algorithms which operate on a specified folder,
processing all layers found there, and allowing these generated
outputs to be utilised in other model steps (e.g. packaging
all of them, merging them, etc)
Since the underlying issues with the Python bindings are now fixed,
in most cases we can safely default to allowing an algorithm to
run in a background thread!!
So now we make this the default, and require individual algorithms
which are NOT thread safe to declare this. This includes algorithms
which directly manipulate the current project or layers (such as
setting layer styles), alter the selections in layers, or which
rely on 3rd party libraries (for now, SAGA and GRASS algorithms
are marked as not thread safe... TODO - someone more familiar with
these libraries can investigate and remove the flag if appropriate).
Also models are marked as non-thread safe. TODO: only flag an
individual model as thread-unsafe if any of its child algorithms
report this flag.
options should be available for certain model outputs and script
algorithm outputs
We do this by swapping the test for non-file based output support
from checking only the algorithm's provider to instead checking
on a parameter-by-parameter basis.
This is done in order to support models. For models, depending
on what child algorithm a model output is based off, an individual
model may or may not have support for non-file based outputs. E.g
a model may generate outputs from a native qgis alg (supporting
these outputs) AND an output from a GDAL alg (with no support
for these outputs). In this case we need to enable or disable
the ui controls for non-file based outputs on an individual
output basis.
For scripts (for now) we blindly just say all outputs support
non-file based formats. This is going to be the case most of
the time, since scripts will usually be written using PyQGIS
API. For the exceptions (e.g. scripts which call other algs
like GDAL algs) we probably should add some way for the script
to indicate whether an individual output supports this, but
for now we just say they all do.
Fixes#17949
Brings the behaviour into line with the styling dock, where
the action is checkable and checked only when the toolbox
is open AND user visible (i.e. not hidden behind another tab). If
the toolbox is open but hidden, then hitting the Toolbox action
brings it to the front tab.
Otherwise it's often necessary to hit to Toolbox shortcut twice -
once to close a hidden toolbox tab, and a second time to open
and raise it.
Ensure that dialogs are always correctly deleted when appropriate.
Also, if an algorithm is running in a background task and hits
an error, we automatically re-show the algorithm dialog and the
associated log for debugging.
Fixes#16858
which cannot run in background tasks
This is not fantastic UX, but we have lots of constraints here:
- The algorithm dialog itself cannot be made modal. There's child
widgets (such as the point and extent parameter widgets) which
interact with the main QGIS window.
- There is no reliable way in Qt to make a dialog modal after
it's shown (e.g. make it modal only when the algorithm is
running). Trust me - I've tried everything, and all approaches
break with some corner case.
- For non-background algorithms, we must have processEvents calls
in order to show the algorithm feedback and progress to users,
and detect cancel button clicks. Yet these processEvents calls
means that users can interact with other parts of QGIS, e.g.
removing layers from a project, and other operations which
could cause the algorithm to crash. So we MUST have some modal
dialog in order to block interactions outside of allowing
the cancel button clicks/progress repainting.
I've tried many approaches, but this is the only one which
works reliably...
the algorithm dialog instead of immediately executing same alg
This allows users to edit the parameters before re-running,
which is a more common user-operation (e.g. changing the
input layer, changing a parameter value "oops, that buffer
was a bit too big....").
If someone wants to exactly re-run the algorithm without changes
it's only one extra click anyway...
