to a new project "capability"
This avoids the unwanted cost of initialising a blank style database
whenever QgsProject::clear is called and project styles are not
required (eg. for server)
Contains methods to serialize/deserialize colors from xml and strings,
where the colors are losslessly stored/restored.
The previous methods for storing colors (Eg QgsSymbolLayerUtils::encode/decodeColor)
are lossy, and only store QColors as 8 bit RGB representations. In
contrast, the new methods store the full lossless representation of
a QColor, including support for 16 bit color components, extended
RGB color components, and storage of HSL/HSV/CMYK color specifications
using their original color components instead of RGB components.
When these new methods are used in place of the existing lossy methods,
they open the possibility of 16 bit color support for QGIS symbols/projects,
(and potentially future CMYK color support).
and make opt-in for non-app clients
There's a tricky initialization balancing act happening here -- but
if we try to load the default style on a system missing the fonts
referenced in that style, then we risk trying to download those
fonts before the QgsNetworkAccessManager is ready.
So play it safe and defer all font download handling until the
QGIS app is fully launched.
available for use in QGIS
Allows for use of fonts which aren't installed system-wide in QGIS, e.g.
when the user does not have permission to install fonts on a system.
This enhancement exposes any WMTS "time" dimensions for use in the
temporal framework, including allowing these layers to be animated
and controlled via the temporal controller.
There's some complexity involved here, because the WMTS specification
does NOT dictate how a time dimension should be exposed by services.
So different WMTS services are all handling this in different ways,
and we need to try to be as tolerant as possible.
Specifically, WMTS dimension values are just free-form strings, so
I've encountered a range of datetime formats -- e.g. "2021", "20210203",
"2021-02-03", "2021-02-03T12:13:14Z", and even WMS(T) style time
period designations ("2021-01-03T12:13:14/2021-01-05T12:15:11/P10M")!
These different formats all need special handling in order to correctly
interpret them as a date time value, and to be able to re-encode
an arbitrary datetime value back to the format string required
by the service. It's highly likely that we'll encounter additional
format strings when this feature is rolled out, and we'll need to
handle each individually.
When we do detect a time dimension on a WMTS layer, we no longer
expose this in the same way as other non-time dimensions. The browser
panel does not show the dimension values, and adding the layer
via Data Source Manager no longer prompts the user to pick from
the available time values. Instead, these layers are indicated with
a new "time capable raster layer" icon, and are added to a project
WITHOUT the user picking a specific time value.
Just like a WMS(T) layer, when a time-dimension enabled WMTS layer
is added to the project, it will default to the "automatic" temporal
mode, meaning that the layer will follow the temporal controller's
current time range by default. A user can then opt to show a specific
static time value for the layer through the layer's Temporal properties
page, by unchecking "Dynamic Temporal Control" and picking a specific
available time range from the "Predefined date" option. (Basically,
the user interaction and experience with a WMTS time enabled layer
is identical to with a WMS(T) layer).
Fixes#48364
