The old behavior was to always fall back to 0 in case of a failing expression. Which made it hard to create a proper legend in some cases.
E.g. if you had two symbol layers with the following expressions for their rotation
"orientation"
And
90 + "orientation"
which would be two orthogonal symbol layers (e.g. denote a right angle), rotated by an orientation field.
Now in the legend (and symbol preview), both layers would be shown with a rotation of 0, because there is no associated feature with a field orientation.
The new behavior is to fallback to the static, configured values which makes it very intuitive to configure the legend for these cases.
When calculating data defined values, this will be counterproductive.
A field with a data defined value might work well in the expression builder (because fiels are all present) but fail in the legend, because it's rendered with no feature and hence fields. With this change, we can at least use `try("fieldname", 0)` to fallback to a default value.
to the direct getters/setters, correctly use the explicit getters and
setters wherever possible.
Makes the code easier to read and more consistent -- now params should
only ever be used for "extra", context specific stuff instead of
commonly user authentication parameters.
* [feature] support datasets with data defined on faces in mesh calculator, fix#30219, fix#30170
added "driver" and "group name" to the calculator interface.
MDAL now supports 3 drivers for storing results, so user must be able to choose appropriate driver and dataset group name (some drivers store multiple groups to 1 file)
since then would be aliases and upper-/lower case written fieldnames be accepted in
extensions and avoid a crash in getSpatialiteFieldNameFromUserVisibleName
instead of using only one ThreadPoolExecutor for all MetaTiles, its now handled in a loop and new ThreadPools for the next zoom level will be started when all work for the previous one is already done. i guess, this will fix the issues and interferences described in #32471 and shouldn't be much slower.
but show a huge obnoxious "NOT OFFICIALLY SUPPORTED" warning
SAGA 7.3 is the new SAGA LTR, so we eventually need to move towards this.
But adding full support is going to be a painstaking tedious process. So
allow users to use this combination, but totally at their own risk.
TODO: Make SAGA provider a 3rd party plugin only and save QGIS core dev sanity ;)
be shown to users when using that provider
This can be used to return a translated warning message which should be
shown to users of this provider. It's intended for use in cases such as
a provider which relies on a 3rd-party backend, where the version of the
backend software is not officially supported, or for alerting users to
providers in a "beta" or "untrustworthy" state.
- For project : check visible state for embedded layers inside an unchecked group, instead of putting all layers in embedded-invisible-layers
- For theme : Add an 'checked-group-node' to save group visible state independently to layers in it.
Fixes#33097
