initAlgorithm() method
This allows 2 benefits:
- algorithms can be subclassed and have subclasses add additional
parameters/outputs to the algorithm. With the previous approach
of declaring parameters/outputs in the constructor, it's not
possible to call virtual methods to add additional parameters/
outputs (since you can't call virtual methods from a constructor).
- initAlgorithm takes a variant map argument, allowing the algorithm
to dynamically adjust its declared parameters and outputs according
to this configuration map. This potentially allows model algorithms which
can be configured to have variable numbers of parameters and
outputs at run time. E.g. a "router" algorithm which directs
features to one of any number of output sinks depending on some
user configured criteria.
destroyed by the python garbage collector
The code generated with the /Factory/ annotation was not sufficient
to correctly transfer the ownership of objects created in Python
back to c++ (despite mailing list messages which hint that it
is).
Anyway, this awful abomination works. Let's all move on to more
useful ways to spend our time...
and pure virtual createInstance
Allows us to add logic which always need applying within
create(), leaving createInstance() free to just return a
raw new instance of the class
Well... kind of. It fixes the toolbar button size, but for some
reason the actual icon content itself isn't being resized. I can't
work out why this is...
The previous naming was too easily confused with processing outputs.
Rename them to QgsProcessingParameterFileDestination, etc... to
make it clearer what they are used for.
This is useful in some cases when working on a third party app/script
that only uses qgis_core. For example, I am working on qgis 3D project
and it is useful to be able to build QGIS core lib with custom Qt version
without having to spend too much time building what I do not need.
Also may be useful for QField to simplify the build of QGIS as a dependency
(no QScintilla, Qwt) and avoid bits of code in providers that would not
be used anyway.
No real source code changes, just configuration changes, mainly in providers.
model execution
And use this function to determine in advance dependencies between
child algorithm parameters with expression based values and
which other child algorithms they depend upon.
Contains variables for model parameters, algorithm results for
other child algorithms which are not dependent on the
algorithm.
Allows removal of final pieces of ModelerAlgorithm code
The expression is evaluated just before the child algorithm is
executed, so can utilise results already calculated by other
children in the model through the use of expression context
functions
converted to QgsMapLayer objects with the ownership transferred
to the Python caller
This should make it super-easy for PyQGIS scripts to run processing
algorithms and immediately utilise the results, even if they
are memory layers. They call processing.run(), and get a dict of
results back which includes those layers ready for adding to the
current project or doing some other processing or operations
with, and if they don't transfer to ownership off then these
layers will be correctly garbaged collected by Python.
- remove temporary layers from context, delete them as soon as they
are finished with
- directly remove features via data provider, instead of selecting
and using edit buffer
- use native geometry methods for splitting to single features
and removing rings
