Allows users to override the line placement settings (e.g.
above/below/on line options) on a per-feature basis. Somehow
this one was the only(?) setting from labeling which
was missing a data defined control...
These methods either
- only wrap QSettings values (so there's no added security gained
by not exposing them -- it's currently easily possible to achieve
the same results via direct QSettings manipulation)
OR
- are required to allow fully automated QGIS deployment/startup
scripts which rely on auth manager functionality
* Emit newProject after save project as ...
Fixes#29919
* Use QgisApp::projectSavedAs signal when project is saved with a new path
* Update browser project home path when saved as
* Set home path when reading a project
* Emit homePathChanged in any case
Now, proj will search in the current user profile "proj" folder (e.g.
.local/share/QGIS/QGIS3/profiles/default/proj" on linux) for
grid files and other proj helper files.
This allows users (and plugins) to install grid files and make them
available for use in QGIS without requiring administrator access
to the system.
This reworks (on proj 6 builds only!) QgsCoordinateTransformContext
to use proj strings of proj coordinate operations to handle the
users' preferred list of operations when transforming coordinates
between two CRSes.
Previously, the context heavily utilised internal transform ID
numbers, which were QGIS specific and relied on matching entries
from the QGIS srs.db file. This approach was undesirable because
it meant QGIS had to maintain and carry it's own table of
possible transform pathways between CRS pairs (which was difficult
to update, impossible to track, and most likely severely out of
date).
Now we can utilse Proj 6's (wonderful!) logic for determining the
best coordinate operation to utilise between two CRSes. All the
old API has been deprecated and no longer works under proj 6, but
that's unavoidable (and unlikely to be in use by plugins anyway,
it's VERY low level stuff).
A further bonus of this work is that QgsCoordinateTransform no
longer relies on proj strings of the source/dest CRS to build
the transform -- the issue with that approach was that proj
strings are lossy (and not always possible to generate), so
now by default we are generating better pathways between CRS
pairs.
This resolves issues with transforms which rely on pivot datums,
such as GDA94 - GDA2020 conversions.
Sponsored by ICSM
Fixes#21986
plus:
- fix multiple string keys with commas in value relation widget
- more robust JSON and array (un)marshalling
- uniform array representation in value relation widgets
- lot of test coverage
- automatic QVariant type conversions in JSON utils
In processing, if an algorithm has a boolean as an output, it cannot be defined as boolean but as a number.
To be more precise in algorithms description, the commit add QgsProcessingOutputBoolean.
Previously only a "layer clipping extent" was available for retrieval
from a QgsRenderContext instance, yet there's a need for rendering
operations to have access to the original full extent of the map
being rendered.
