This is the base API interface classes for creation of custom
2d or 3d map controllers, and registering them in a common
QgsInputControllerManager singleton class.
the text annotation should handle map rotation
Previously, text annotations just ignore map rotation, which
matches how regular map labels are handled. But this is not
desirable for some point text annotations, where it can
be considered a bug that the item ignores the map rotation (eg
when a text annotation has been placed to align with a feature
on the map, such as a road)
There's no one "correct" behaviour here, so add a new
combo box widget in the annotation point text settings with
options for
"Ignore Map Rotation"
"Rotate With Map"
so that users can pick the desired behavior for their annotations
always be used for the layer (as opposed to any previously
stored matrix sets)
For some vector tile data providers this is more appropriate --
specifically for those with tilemap information where we MUST
ensure that the tilemap matches the data source or missing
tiles may be present. (If we store the matrix set information
in projects then loading older projects may mean that a stored
tilemap is out-of-sync with the actual data source's current
tilemap).
This allows us to correctly handle "indexed" vector tile sets,
where higher zoom level tiles may be missing where a lower
zoom level tile is deemed to have sufficient detail for higher
zoom levels.
This container always lays out child widgets in a horizontal
row, where the number of columns is automatically determined
by the number of child widgets.
It's useful for creation of compact forms, where no space will
be wasted by assigning extraneous horizontal width to widgets
where the expected values will always be short.
Eg: creating 3 rows with 3, 2, 1 child widgets respectively
results in the layout:
Attr 1: [...] Attr 2: [...] Attr 3: [...]
Attr 4: [..........] Attr 5: [..........]
Attr 6: [...............................]
Without the option of row containers then the all horizontal
rows will have the same number of columns, eg:
Attr 1: [...] Attr 2: [...] Attr 3: [...]
Attr 4: [...] Attr 5: [...] Attr 6: [...]
(leaving insufficient horizontal length for attributes 4-6), or
Attr 1: [..........] Attr 2: [..........]
Attr 2: [..........] Attr 3: [..........]
Attr 4: [..........] Attr 5: [..........]
Attr 6: [..........]
(resulting in wasted horizontal space next to attribute 6, and
an extra row taking up vertical space)
Sponsored by NIWA
QgsAbstractDatabaseProviderConnection
When implemented by providers, will provide a method for
permanently setting field aliases/comments within a
database
Here we have no choice but to create a new Capability2
enum, as the original Capability has now consumed the
entire range of values for data types permitted by QFlag
datasources which support editing comments
This support is currently limited to the postgres provider,
so exposing the comment field for all other vector layer types
is just misleading to users. The comment will be completed discarded
without any warning!
This enum can be used in the QgsProcessingUtils::mapLayerFromString()
and parameterAsPointCloudLayer() calls to control layer loading, e.g.
skipping index generation or not applying default style, etc.
This adds the API framework for storing additional, semi-structured
properties inside QgsField objects. The intention is that strong
field-type specific properties can be stored.
Eg for a geometry field type coming from the postgres provider
the metadata can be used to store the associated CRS and WKB types
so that clients can be aware of the correct format required for
geometries stored in that field. Instead of cluttering the QgsField
API with specific getters/setters for properties like crs(), wkbType(),
etc which only apply for a certain field type, the metadata map
approach helps us keep the API nice and slim.
The API has been designed to follow the approach used by various
Qt objects (such as QTextFormat) where a preset set of keys
are exposed as an enum, but additional ones can be used for
custom property storage. This allows for a more structured
use of properties with conventions which apply across different
providers (as opposed to a free-form string key approach).
Refs #49380