All user settings/plugins, etc are now loaded from APPDATA for each
platform and no longer .qgis3 and are isolated from each other.
This allows for different profiles depending on what the user of QGIS
needs, e.g test, prod, demo, etc
Profile menu allows for switching between profiles, or creating new
ones.
Instead of duplicate labeling specific unit enum, reuse
the QgsUnitTypes::RenderUnit enum in labeling.
This brings several improvements, including:
- label offset/distance/repeat units now works correctly
in all available unit types (inc pixels, map unit meters,
points, inches, etc)
- less duplicate code
- labeling can use the robust QgsRenderContext methods for
converting between different units and painter coordinates
Also change comments for members to doxygen comments, so
that these get included in the API docs.
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).
