std::sort is returning a slightly different sort order when
label z order (or label cost) is equal
Given that the order in these cases is effectively arbitrary
I've updated the test masks to accept either order.
Why?
- no benefits to QScopedPointer over std::unique_ptr
- unlike QScopedPointer, std::unique_ptr has no overhead
over regular pointers
- using standard language features makes it more likely that
compilers can optimise this use and static analysers can
correctly handle code using unique_ptrs
- QScopedPointer has an (IMO) uncertain future (given that
Qt is dropping features which have become part of the c++
standard). Better to port now before wider use of QScopedPointer
in the codebase!
In some cases the render result for a layer may depend on more than
one layer.
This changes QgsMapRendererCache to use "cache keys" instead of layer ids
to identify images within the cache. When setting an image inside the
cache, a new list parameter is used to specify all layers on which
that image depends.
The basic idea is to split reading of XML definition and resolution of layer IDs into layers.
Also includes some cleanups in QgsProject and improvements in QgsVectorLayerJoinInfo.
Faster than QgsGeometry::isGeosEmpty() because it avoids the
conversion to GEOS geometries and just uses the QgsAbstractGeometry
subclasses directly.
Also implements faster isEmpty() overrides for specific
QgsAbstractGeometry subclasses.
This changes the rendering of annotation frames to use QGIS' symbology
engine, which means that all the existing fill styles can now be
used to style annotation frames.
Also paint effects & data defined symbol parameters. Whee!
Not an ideal implementation (too much logic resides in the
gui QgsMapCanvasAnnotationItem class), but any approach
using current api will be dependant on some hacks.
Ideally we need a QgsVectorDataProvider method for finding
the closest feature(s) to a point(/line/polygon) within a
certain tolerance, with provider specific implementations
which offload this to the data store's spatial indices.
Then this handling could be bumped up to reside in
QgsAnnotation.
Previously only some annotations had (incomplete) support for
attaching to a particular vector layer and synchronising their
visibility with the layer's visibility.
This handling has all been moved up to QgsAnnotation, so that
all annotation types can be attached to layers.
This will allow selective annotation visibility based on the
visible layers of a particular canvas, eg in multi-canvas
environments.
Additionally:
- show the attached layer in the annotation properties
dialog, and allow it to be cleared to always show the
annotation
- allow attaching annotations to non-vector layers
- add unit tests for visibility
Splits the rendering component of annotations out from map
canvas item component.
A new core abstract base class QgsAnnotation handles the
management of the common properties associated with an
annotation, and handles rendering the annotation onto a
QgsRenderContext destination.
Existing annotation classes have been ported to this, and
with the exception of the form annotation moved into core.
Form annotations are dependant on editor widgets and must
remain in GUI.
A new QgsMapCanvasAnnotationItem item class implements
a QgsMapCanvasItem which draws an annotation inside the
canvas, and handles synchronising the position and size
of the canvas item with the QgsAnnotation position/size.
This allows annotations to be safely used in a multi-canvas
environment, with a single QgsAnnotation being displayed
in multiple canvases (even if the canvases have different
extent/crs/etc).
Additionally it allows annotations to be directly rendered
to a map (eg in composer) without going through the
gui based Qt graphics scene framework.
Also removes lots of duplicate code, and adds some basic
unit tests for annotations.
