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.
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
In certain circumstances very proximal nodes could cause instability
in the ellipsoidal area calculation.
Port (slightly tweaked) fix from grass changeset 71167 for same issue,
and add a unit test
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.
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
Since it's safe to evaluate parameters in background threads
now, it's usually going to be ok to evaluate everything in
the processAlgorithm step.
This keeps the algorithm code as simple as possible, and will
make porting faster.
Note that the prepare/postProcess virtual methods still exist
and can be used when an algorithm MUST do setup/cleanup work
in the main thread.
add to the current context
With appropriate note and tests to ensure that both the current
context and that which the results being taken from share the
same thread affinity
The button can now be used in two different modes. The default behavior
is to include all settings used for configuring
QgsTextFormat/QgsTextRenderer classes. A cut down mode (without settings
for color/buffer/drop shadow/etc) is also available when the resultant
font is to be used only in a QFont object.
A standard widget for configuring text format properties for use
with QgsTextRenderer/QgsTextFormat.
It's modelled heavily off QgsColorButton, and supports lots of nice
things like dragging formats between buttons, copying and pasting
format settings, dropping colors from color buttons, dragging colors
from font buttons to color buttons, directly setting font size
and opacity/color without having to open a dialog.
