Instead of duplicate labeling specific unit enum, reuse
the QgsUnitTypes::RenderUnit enum in labeling.
This brings several improvements, including:
- label offset/distance/repeat units now works correctly
in all available unit types (inc pixels, map unit meters,
points, inches, etc)
- less duplicate code
- labeling can use the robust QgsRenderContext methods for
converting between different units and painter coordinates
Also change comments for members to doxygen comments, so
that these get included in the API docs.
direct QPainter argument
This will make use of other rendering code within layout items
much easier - since symbology/text renderer/diagrams/etc all
require QgsRenderContexts for use, it makes sense for
layout item rendering to also use this approach.
This also avoids lots of duplicate code which was scattered
throughout different composer item types to manually handle
creation of QgsRenderContexts when required.
This allows optional outputs (such as null geometry features detected
by the Remove Null Geometries algorithm) to be skipped by default
when desirable.
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.
Instead of relying on forward declared c++ classes from
gui in QgsLayoutItemRegistry, instead create a
QgsLayoutItemGuiRegistry which handles registration
of all the GUI specific behavior relating to layout items.
Remove all GUI related code from QgsLayoutItemRegistry.
This creates a cleaner split between core/gui code, and
given that there'll be a lot of gui specific behavior
which needs to be handled by a registry it makes sense
to keep this isolated in gui.
It also plays nicer with the sip bindings, which can't
handle forward declared gui classes in core.
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.
