to control whether selected features only are to be used
Replaces the old global setting and makes it immediately obvious
to users when the selection will be respected
This somewhat changes the meaning of outputs from processing 2.x.
In 2.x processing outputs were used both as a method of specifying
inputs to algorithms (file paths to destination layers created
by the algorithm) AND pure outputs (such as statistics calculated
by the algorithm).
This is now split. The old input-type-outputs (destination layers)
are now input parameters (since the parameter value IS an input to the
algorithm). To differentiate them from parameters indicating pure
input layers a new "isDestination()" method was added to
QgsProcessingParameterDefinition.
Output definitions are now purely indications of values CREATED
by the algorithms. Suitable candidates are the existing calculated
stats and actual file path/URI of any layers created by the algorithm.
Moving forward we should ensure all algorithms output as much
useful information as possible - e.g. number of features processed,
number of skipped features, count null geometries encountered, etc...
Subclasses should use this method instead of directly calling
QString::contains or using Python 's in search' type matches.
This ensures consistent matching behaviour across different filters.
Filters can indicate their preferred search prefix. Searches which
begin with this character will be restricted to the single matching
filter.
E.g. entering 'l buffer' will searching only layers containing 'buffer'
Other prefixes are:
- . search actions
- pl search print layouts
- a search algorithms
Plugins are restricted to a minimum 3 character prefix. We do this
to avoid plugins 'stealing' desirable prefixes, and instead we
want to reserve them for future core filters.
Higher priority (i.e. more important) filter results get shown
first. This means filters like project layers & composers will
show above 'cruder' filters like the actions/processing filters.
Algorithms and other processing code should use this method
(instead of dataobjects.getLayerFromString) to
retrieve layers from a string, as it considers the processing
context and allows resolving strings to temporarily stored layers.
This permits processing models to function correctly when
intermediate results are stored as memory layers. Subsequent
model algorithms can then access these temporary layers as inputs.
All temporary layers will be removed when the context object
is destroyed after the model algorithm is run.
