filter, ensure the progress bar is removed when the algorithm
finishes
Otherwise it hangs around in the message bar until it's manually
dismissed, unlike the behavior when you run an in-place operation
through the toolbox.
This button isn't a cancel button - it just closes the dialog, and
doesn't abort any changes which have already been made as a result
of running the algorithm through the dialog.
```
File "/home/mkuhn/.local/share/QGIS/QGIS3/profiles/default/python/plugins/autocurve/plugin.py", line 127, in curvify
AlgorithmExecutor.execute_in_place(alg, {})
File "/usr/share/qgis/python/plugins/processing/gui/AlgorithmExecutor.py", line 305, in execute_in_place
ok, results = execute_in_place_run(alg, parameters, context=context, feedback=feedback)
File "/usr/share/qgis/python/plugins/processing/gui/AlgorithmExecutor.py", line 214, in execute_in_place_run
results, ok = {'__count': current + 1}, True
UnboundLocalError: local variable 'current' referenced before assignment
```
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.
don't raise a generic "something went wrong" exception but instead
ensure that the original exception with the proper error message
is raised for catching in Python instead
(e.g. parameters) when they are run in the "edit in-place" mode
This allows algorithms to dynamically adapt their behavior to make them compatible
with in-place mode. Previously, some useful algorithms could not be
run in-place because they alter a layer's structure (e.g. adding new
fields).
Now, these algorithms have a means to detect that they are being
run in-place and change their input parameters accordingly. E.g.
an algorithm which usually adds new fields to store calculated
values (such as "add xy fields to layer") could instead expose
field parameter choices to ask the user to pick from existing
fields in which to store the calculated values, thereby avoiding
the need to change the table structure and making them eligable
for running in-place mode.
Note that this needs to be handled algorithm-by-algorithm, it's
not automatic! It's just the raw api to allow this...
Offers the same functionality as the Random points inside polygons
algorithm, and in addition it includes (possible to opt-out) the attributes
from the containing polygon and the ability to specify a seed for the random
number generator.
Could replace the Python algorithm Random points inside polygons, but
this C++ implementation only supports "Points count" ("number of points
for each feature") directly, while "Points density" is supported by allowing the
point count to be data defined (using the polygon area to calculate the
number of points).
