(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).
actions to the "Autofill" menu
This adds more UI consistency, as currently there's a disconnect
from the autofill options available via the Autofill buttons
vs some options which need to be done from the first rows "..."
button
feature sources, instead of requiring them to be loaded into a project first
This change allows users to directly browse to non disk-based layer sources
for any processing feature source inputs. It allows these inputs to be
taken direct from postgres, sql server, oracle, wfs, afs, etc layers directly
without having to first load them into a project!
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.
