Move all scalebar rendering code out of composer and ensure that
all scalebar rendering is done independant of QgsComposerScaleBar
This allows scalebar rendering code to be reused by plugins
and by non-composer code.
Also rename QgsScaleBarStyle -> QgsScaleBarRenderer, (and all
subclasses too). This name better reflects what these classes do.
Instead of creating them for all items when composer window
is opened, instead just create and destroy them when
required. None are too heavy to have a noticable delay
when selecting items, but in contrast keeping them around
forever is wasteful on memory.
Also clean up a lot of duplicate composer/composition
code and remove unnecessary signals from api (use a single
itemAdded signal instead of multiple signals for every
item type)
This adds a new QgsLayoutManager class which is used for
storage and serializing/deserializing of compositions.
A QgsLayoutManager is attached to QgsProject. This allows
core code to access the compositions attached to a project.
The intention is to move all handling of compositions from
app to core, making it easy for server to access project
compositions without resorting to fragile xml parsing.
This change is being driven by:
- need for consistent terminology in the api. Currently there's
a confusing mix of border/outline used
- need for consistent terminology in the gui - we have a mix
of "border"/"outline"/"pen"
- bringing QGIS into line with the standard terminology used
in other graphic editing programs
This commit implements a new QgsAnnotationManager class, which
handles storage, writing and retrieval of annotations.
QgsProject has an annotationManager() attached to it. Map canvases
sync their visible QgsMapCanvasAnnotationItems to the annotations
contained within the project's annotation manager.
This moves all management, storage and retrieval of annotations
up to core and out of app/canvas.
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.
Remove QgsAbstractProperty and subclasses, and instead use a single
QgsProperty class which covers the use of QgsAbstractProperty
and its subclasses. This simplifies the API and avoids pointer
handling. QgsProperty is implicitly shared for memory efficiency
and inexpensive copies.
And overriding projection is only done if user has manually
chosen a different CRS from the list.
This means that templates and compositions in server can still
adapt to follow the project CRS, but if desired specific map
items (eg an overview map) can use the CRS override to always
show in a particular CRS.
This allows the CRS for map items to differ from the canvas/project
CRS. It also allows different map items to have different CRS,
eg an overview map can be set to a different CRS to the main map.
An unfortunate side effect of this change and the ongoing work
to separate compositions from canvas is that datum transforms
are no longer supported in composer. This cannot be fixed until
the datum transform store is rewritten to not depend on canvas
(ie, it's also broken for upcoming multi-canvas work)
Use relevant composer map item CRS instead of composition mapsetting's
CRS. For items directly linked to a map (eg scalebar, legend) we
use that map's CRS, for others (eg labels, html items) we use the
composition's reference map CRS.
(Note that the CRS cannot be set for a map, and is still currently
linked to the canvas CRS. Fixing that is a future TODO.)
This method was used to sync the canvas layers to a composer map.
The logic has been moved to app to avoid a dependancy between
compositions and the main map canvas
draw shape/arrow/nodes/paper symbols
This commit removes some more instances where changes in the
canvas affect compositions. Previously the symbols drawn
in shape/arrow/etc items were using the scale from the canvas.
This meant that the appearance of these items in composer
would change depending on canvas zoom if they used symbols
with map unit sizes.
Now they take their map scale from the composition's reference
map. While this has the nice side effect that now map units
can be used in the appearance of these items and they're
guaranteed to match up with the reference map item, the main
intention here is to remove more of the forced links between
compositions (core) and the main canvas (app).
This option will be used for more than just world file generation,
and instead will indicate which map should be considered the master
map for the composition from which any composer properties
calculating map units will derive the scale from.
spell check will be done automatically in words by default (when some conditions are fulfilled)
possibility to avoid in words checking by adding :* at the end in spelling.dat
one can add #spellok at the end of a line of code to skip spell check on this line
