values are automatically updated when the combo box unit changes
This means that you can flip between units and things like
the existing width and height are converted immediately to the
new unit
- composer shape style button (no other composer ones for now- they're
all getting removed with layouts anyway)
- point cluster/displacement renderer buttons
Button widgets for configuring symbol properties were reimplemented
multiple times throughout the codebase. This commit creates a new
standard QgsSymbolButton widget which should be used whenever
a button for configuring symbol properties is required.
Features include:
- automatic use of inline panels whenever possible
- dropdown menu with shortcuts to color settings, copy/pasting colors
- accepts drag and dropped colors to set symbol color
All signals are now in the base class, even if only
a subset of available providers actually emits them.
This way we can handle all source select dialogs
the same way, regardless if they are vector, DB
or raster (or others).
This modification was necessary because the current implementation
of the source select dialogs within the unified add layer dialog
create the provider dialogs the first time and do not destroy
them, this means that the canvas extent and CRS can change from
a dialog invocation to the next and the extent and CRS need to
be updated at layer creation time.
For now it's only for WMS but you get the idea.
There is a new abstract base class for the source select
dialogs, that will grow with common behavior for all
the select dialogs.
Signals are forwarded from the (root) data items to the
app and then delivered to the various browser instances
and to the unified layer dialog.
A change in one of the browser items should trigger a
refresh in all the other browsers and dialogs.
This allows the designer dialog to group the corresponding item
actions together (i.e. grouping all basic shape creation actions
together), but without any hardcoded special handling so that
plugin based items can also be grouped.
When adding a new item to a layout, if the user just does a single
click of the mouse (vs a click and drag to set the new item
position/size), then a dialog is shown asking to user for
the new item size/position/reference point.
This allows easy creation of items with an exact position/size
and is common behavior in most proper DTP/illustration apps.
Instead of relying on forward declared c++ classes from
gui in QgsLayoutItemRegistry, instead create a
QgsLayoutItemGuiRegistry which handles registration
of all the GUI specific behavior relating to layout items.
Remove all GUI related code from QgsLayoutItemRegistry.
This creates a cleaner split between core/gui code, and
given that there'll be a lot of gui specific behavior
which needs to be handled by a registry it makes sense
to keep this isolated in gui.
It also plays nicer with the sip bindings, which can't
handle forward declared gui classes in core.
