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
This registry is attached to QgsGui and handles registration of
functions which create widgets for modifying QgsAnnotationItems
Modeled heavily off the print layout API
[feature] [mesh] allows the user to make geom transformation of mesh frame by changing the vertices coordinates by expression. Each coordinates (X,Y,Z) of selected vertices can be calculated with an expression allowing transformation of the mesh while the mesh is still valid.
Co-authored-by: Harrissou Sant-anna <delazj@gmail.com>
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 ;)
* mesh expression $vertex_as_point $vertex_Z_value
* functions help
* SIP, doc and indentation
* fix SIP
* fix help file
* change function name and add Meshes group description
* fix typo
* fix strings and docs
* typo