* [FEATURE] adds undo/redo for transaction groups
[needs-docs] the undo/redo now works with transcation groups. Just check
that there is no restriction in the transaction groups doc concerning
undo.
related to #14799
The undo/redo is implemented using SAVEPOINT.
The QgsTransaction interface has been enlarged to allow savepoints
creation and management. The savepoint is destroyed on
rollbackToSavepoint to have the same behavior has the sql ROLLBACK TO
SAVEPPOINT.
To avoid the creation of a savepoint for each feature modified in bulk
editing (e.g. paste, field calculator) the logic is a bit complicated: the
savepoint is created on QgsVectorLayer::editCommandStarted and the first
actual undo command (QgsVectorLayerUndoPassthroughCommand) is
responsible for the re-creation of the savepoint in case of undo-redo.
Since the behavior must be different in case edition doesn't take place
inside an edit command, a member function has been added to
QgsVectorLayer to expose the mEditCommandActive state.
Another (commented) tricky bit is the modification of the database
structure on add/delete attributes. On undo, the attribute is removed
before the rollback to savepoint, i.e. there is a useless ALTER TABLE
issued to restore the structure just before restoring it with the
ROLLBACK TO SAVEPOINT. This is necessary to make the provider
aware of the change of structure. It could be nicer/cleaner to have a way
to reload providers metadata.
The editPaste function has also been modified to use addFeatures instead of
addFeature (plural/singular), this is at the expense of an additional "cpy"
of the clipboard in memory, but it should improve perf with postgis provider.
* fixup operator aliases
Make sure that results from a feature counter will only be delivered on
the main thread and that they will be discarded if the layer is deleted
meanwhile.
Flags can be used to control how features are added to the sink.
For now, there's only a single flag available - FastInsert.
When FastInsert is set, faster inserts will be use at the cost
of updating the passed features to reflect changes made at the
provider.
This includes skipping the update of the passed feature IDs
to match the resulting feature IDs for the feature within
the data provider.
Individual sink subclasses may or may not choose to respect
this flag, depending on whether or not skipping this update
represents a significant speed boost for the operation.
QgsVectorLayer always ignores the flag - feature ids are
required for the featureAdded signal to be correctly emitted,
and it's expected that performance critical applications will
add features directly to a data provider instead of
via QgsVectorLayer's edit buffer.
Historically the configuration used to be stored in layer's custom properties, but that does not scale
beyond simple rendering and so rule-based labeling introduced storage of configuration natively in XML elements.
That left us with two different ways of reading/writing labeling configurations. This work makes all configuration
to use native XML elements.
To keep compatibility of 2.x projects, reading of configuration from custom properties is preserved.
This commit also adds Python APIs for direct manipulation of labeling configuration through vector layer's
setLabeling() and labeling() calls.
This is necessary in order to be able to correctly translate between absolute and relative paths
deeper in the code - e.g. paths to SVG files used in marker or fill symbols.
Until now, relative paths were translated to absolute paths on the fly.
This is now changed - paths to files should be always absolute within QGIS objects - and paths
only get turned into relative when saving projects. When loading a project, relative paths
are translated to absolute paths immediately.
This should lower the overall confusion about relative/absolute paths within QGIS, and also
allow having different base directories for relative paths (e.g. QML or QPT files may use relative paths
to their directory - rather than to the project directory)
