edit operation on an annotation item
This is used for the item to return a representative geometry
of what the item would look like if the operation were to be
applied. It's used to generate a rubber band showing a preview
of the modification during interactive editing operations on
an annotation item.
edit operations on annotation layers, with initial implementation
as QgsAnnotationItemEditOperationMoveNode
This class encapsulates edit operations which apply to annotation
layers/items
For now all nodes just directly represent vertices in the item,
but the intention here is that they can represent any form of handle
which can be used to manipulate an item (e.g. a bezier curve point,
some "smart shape" handle for resizing or rotating an item, etc)
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.
Because some annotation items have scale dependent bounding boxes,
we can only index items which have a fixed bounding box. Other
item bounds need to be dynamically determined based on a specific
render context. So rework the annotation layer index handling
to only index appropriate items and store other items in a non-indexed
item set.
This isn't ideal, because it means we need to clone ALL non-indexed
items upfront whenever we render an annotation layer (it's too expensive
to calculate their actual bounding box and selectively clone them,
as it's a process which blocks the main thread).
Hopefully we can think of an alternative approach to this down
the line so that we DO have some form of spatial index for scale
dependent items, unlocking better performance for annotation layers
with 10,000s of items. But we'll ignore that situation for now ;)
to annotation layers to reflect that while these are editable
users are not able to toggle edits on them (they are ALWAYS
editable!)
Note that we can't use the existing QgsMapLayer::LayerFlag enum here,
as that has a different meaning (flags which are set by users
at runtime)
- Add enums to qgis.h instead of qgscoreenums, so that they belong to
a Qgis namespace
- Split up the various symbol headers into multiple files so that we
can fine-tune their inclusion and forward declare more readily, speeding
up recompilation
- Move QgsSymbol enums to qgis
All the logic for rendering non-opaque layers is handled in a layer
type agnostic way already, so this just allows the existing handling
to be used for mesh/point cloud/vector tile/etc layers also
work correctly with curved geometry types, and tweak some API naming
accordingly
There's no need to be restrictive and only require linear geometries
for these items!
