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.
Allows upgrading geometries to include these dimensions, or
overwriting any existing Z/M values with a new value.
Intended mostly as a test run for QgsProcessingFeatureBasedAlgorithm
An abstract QgsProcessingAlgorithm base class for processing algorithms
which operate "feature-by-feature".
Feature based algorithms are algorithms which operate on individual
features in isolation. These are algorithms where one feature is
output for each input feature, and the output feature result
for each input feature is not dependent on any other features
present in the source.
For instance, algorithms like "centroids" and "buffers" are feature
based algorithms since the centroid or buffer of a feature is
calculated for each feature in isolation. An algorithm like "dissolve"
is NOT suitable for a feature based algorithm as the dissolved output
depends on multiple input features and these features cannot be
processed in isolation.
Using QgsProcessingFeatureBasedAlgorithm as the base class for feature
based algorithms allows shortcutting much of the common algorithm code
for handling iterating over sources and pushing features to output sinks.
It also allows the algorithm execution to be optimised in future
(for instance allowing automatic multi-thread processing of the
algorithm, or use of the algorithm in "chains", avoiding the need
for temporary outputs in multi-step models).
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.
direct QPainter argument
This will make use of other rendering code within layout items
much easier - since symbology/text renderer/diagrams/etc all
require QgsRenderContexts for use, it makes sense for
layout item rendering to also use this approach.
This also avoids lots of duplicate code which was scattered
throughout different composer item types to manually handle
creation of QgsRenderContexts when required.
