Usually a geometry generator expression must return a geometry
in the associated layer's CRS. But this doesn't work in situations
where a geometry generator symbol is NOT associated with a layer,
e.g. when used in a layout item.
So add a new option to allow users to specify which unit the expression
will return geometries in, with choices of map units (the default,
previous behavior), millimeters, pixels, inches and points.
When millimeters, points, inches or pixels is selected then
the @map_geometry variable will be available for the expression,
and contain the feature's geometry in the specified units (relative
to the map frame). (The $geometry variable remains available and
still in layer CRS, in case an expression needs to calculate the
original area, perimeter, etc in real-world units while returning
results in a different unit!)
A step toward fixing #39159
This code corresponded to a "not a vector layer" error, which needlessly
prevents the QgsMapToolCapture class from being usable as a base class
for map tools which operate on non-vector layers.
There's no reason to restrict this call solely to vector layers
-- it's useful to have accessible for adding geometries associated
with other layer types too.
If we require all annotation item map tools to inherit from
QgsMapToolAdvancedDigitizing, then we lose the flexibility to
subclasss other map tools for annotation item creation (e.g.
QgsMapToolCapture)
when we are editing annotation items, as properties of the item
which aren't exposed in the widget (e.g. it's geometry) may
have changed in the meantime and we don't want to lose those.
This class encapsulates the context in which a map layer config
widget is being shown (e.g. the corresponding map canvas, message
bar and other properties useful for the config widgets)
This registry is attached to QgsGui and handles registration of
functions which create widgets for modifying QgsAnnotationItems
Modeled heavily off the print layout API
This is the start of a map tool for interactive editing of items
in annotation layers. Currently it supports selecting items, and
pre-highlighting their nodes as the cursor is moved over the items.
(Not exposed in QGIS gui yet)
renderer operations
This follow a similar pattern as how labeling results could be collected
after a map render job, but generalises the API so that it can be
used for storing details of rendered items of any type.
It's currently used for storing details of rendered annotation items,
so that map tools can retrieve details of annotation items visible
in the canvas in an optimised way.
