This gives more flexibility in future to handle known missing tiles or
other special circumstances (eg falling back to lower
zoom level tiles from the matrix set in certain circumstances)
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
efficiently for many calls
Allows retrieval of some basic algorithm properties (display name,
icon) in an optimised way for many calls. (Avoiding multiple
expensive algorithmById lookups)
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!
