Allows setting symbols other map item sizes to Map Units in Meters. This allows setting the size always in meters, regardless of what the underlying map units are (e.g. they can be it geographic degrees). The size in meters is calculated based on the current project ellipsoid setting and a projection of the distances in meters at the center of the current map extent.
The dialogs are parented to the main window, which means sip
transfers the ownership to the main window - and they are
never deleted as a result. This results in various error
messages caused by the widgets hanging around forever
and listening out for various signals they are connected to.
By initializing the prototype of the algorithm stored in the
provider we allow shortcuts like directly querying the parameter
definitions from the provider's prototype (instead of having
to create a new instance and manually initialize it first)
parameters to an algorithm
QgsProcessingAlgorithm::addParameter() has a new createOuput
argument (true by default).
If the createOutput argument is true, then a corresponding
output definition will also be created (and added to the
algorithm) where appropriate. E.g. when adding a
QgsProcessingParameterVectorDestination and createOutput is
true, then a QgsProcessingOutputVectorLayer output will be
created and added to the algorithm. There is no need to call
addOutput() to manually add a corresponding output for this
vector. If createOutput is false then this automatic output
creation will not occur.
This should simplify declaration of outputs for algorithms
as it avoids the need to manually declare these corresponding
outputs.
This partially reverts commit c7c52442f71a6a17ea1ad97e741b2b4b6d51f698.
Causes a race condition which results in random crashes while
using the categorised symbol renderer.
The intent behind the original commit is unknown
while rendering has already been started for a particular symbol instance
Relates to a random but frequent crash which occurs when using the
categorised symbol renderer - tracked down to a race condition
in which multiple concurrent calls to startRender() are performed
on a single symbol instance.
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
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
