always add a consistent amount of attributes regardless of the
code paths taken
Some algorithms were adding features to data providers with
different number of attributes vs the layer's fields - this is
not supported and depending on the data provider will have
different (bad) results.
be prepared
There's cases where this happens without reflecting an invalid
expression. So we can try to prepare, but not abort if the
preparation fails.
Fixes#18103
- Fix missing format call for string when calculated number
of points is 0
- Fix incorrect progress reports which were spamming the dialog
and causing UI hangs, and slow algorithm execution
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.
And make this support opt-out, since the vast majority of providers
are based on QGIS API and don't have external dependencies which would
restrict use of memory layers/etc.
Plus, I'd rather see non-compliant providers expose this support when
they can't use non-file-based-outputs (and make this the bug which
needs fixing) then have to rely on plugin providers to discover and
explicitly expose this support.
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.
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.
