Ownership of Python subclass algorithm instances was getting
mangled due to passing through multiple functions with /Factory/
annotations.
As per Phil Thomson's advice on
https://www.riverbankcomputing.com/pipermail/pyqt/2017-July/039450.html:
"
/Factory/ is used when the instance returned is guaranteed to be
new to Python. In this case it isn't because it has already been
seen when being returned by createInstance(). (However for a different
sub-class implemented in C++ then it would be the first time it was seen
by Python so the /Factory/ on create() would be correct.)
You might try using /TransferBack/ on create() instead - that might be
the best compromise.
"
Changing to /TransferBack/ indeed fixes the error for me.
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.
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.
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.
