Intended as a registry for the various processing components,
including providers, algorithms and various parameters and outputs.
Currently handles only registration of providers, as a step toward
removing processing's algList (this requires first porting
the algorithm class to c++)
A QgsProcessingRegistry instance is attached to QgsApplication,
and is retrieved by QgsApplication::processingRegistry()
Nothing particularly exciting here yet, but this commit
moves the definition of the provider base class to a c++
QgsProcessingProvider abstract base class.
As part of this some existing python methods were renamed
to make their use clearer and to fit with the QGIS c++
api conventions:
- getName was renamed to id
- getDescription was renamed to name
- getIcon was renamed to icon
These API breaks are documented
spell check will be done automatically in words by default (when some conditions are fulfilled)
possibility to avoid in words checking by adding :* at the end in spelling.dat
one can add #spellok at the end of a line of code to skip spell check on this line
- always use a 1px outline around items, regardless of zoom
- don't change text color for selected items (too hard to read),
instead change outline/box color
- use [close without saving][cancel][save] option when closing
a modeler with unsaved changes
- invert mouse wheel zoom in/out to match that of QGIS' main
canvas window
- holding the mouse middle click and dragging will pan the
modeler view
This adds a new input type for expression inputs. Expression
inputs can be linked to a parent layer so that the builder
shows the correct fields and layer variables.
It's designed for two use cases:
1. to be used when an algorithm specifically requires an expression,
eg Select by Expression and Extract by Expression.
2. to be potentially used as a replacement input instead of string
or number literals in algorithms. Eg - if the simplify algorithm
tolerance parameter was replaced with an expression paremeter, then
this expression would be evaluated for every feature before
simplifying that feature. It would allow parameters to be calculated
per feature, as opposed to the current approach of calculating
a parameter once before running the algorithm. It would also
mean algorithms like "variable distance buffer" would no longer
be needed, as a single "buffer" algorithm could then be used
for either a fixed distance, field based, or expression based
distance.
accept numeric, file and table field inputs in modeler
This allows a non-string parameter to be reused as a string
parameter in contexts where it makes sense.
Tags are used while searching in the toolbox. This should help with
finding algorithms when the exact name is not known, eg
you could search for "envelope" or "bounds" and find the
'Polygon from Layer Extent' algorithm.
At the moment it's quite hard to discover algorithms which exist
when you don't know what their called and have to instead search
for every possible naming variant which could exist...
