And implement some fixes/improvements (refs discussion on the dev mailing list):
- allow user to specify created field name
- allow optional creation of a summary table showing new class value vs original
value
This algorithm has become a model-only algorithm, since it's
functionality is now present in the native c++ buffer algorithm
(which can now buffer by field or expression).
Ideally we'd remove this algorithm entirely, but data defined
parameters are not yet supported by the modeler gui, so we need
to keep it around for use in models for now.
...to help clarify for users what the different input types mean.
Fixes#17671, which is a result of unclear distinction between
the uses of vector features vs vector layer inputs.
Tagged as needs-docs, as it may help with documentation for 3.0
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
A much better way of doing this would be to have the dialog extend qgsprocessingalgorithmdialogbase, or to take an approach like the one used in the raster calculator, with wrapper widgets.
This is just a patch, since that option might require a larger amount of work.
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...
