This fixes a scenario inspired from #39431, but doesn't fix the exact one
of that ticket.
The scenario fixed by this ticket is:
- Enable grouped transaction in project settings
- Open a GeoPackage with 2 layers 'a' and 'b'
- Toggle edit mode
- Create a feature in 'a'
- Create a feature in 'b' -> when validating an error message of database
locked would appear without this fix
The reason is that the 2 layers got opened in 2 separate GDAL datasets,
and this doesn't play well with the grouped transaction mechanism that will
start a transaction in each dataset. SQLite locking will then kick in.
So here we avoid this to happen by making sure the OGRProvider that is used
to return the list of sublayers is closed before opening them. That way the
mechanism in the OGR provider to share the same GDALDataset works.
This actaally explains why the scenario in #39431 still fails. When we
create the second layer, the OGR provider cannot re-use the GDALDataset used
to open the first layer, as it got modified in between (see
https://github.com/qgis/QGIS/pull/5689#issuecomment-346625386 for a case
where this was needed), and in particular doesn't know there are now 2 layers.
So we end up having 2 GDALDataset opened on the same .gpkg file and starting
transactions...
Fixing #39431 would propably require to modify QgsNewGeoPackageLayerDialog::apply()
to possibly use an existing GDALDataset openeded and cached in
QgsOgrProvider::sMapSharedDS global map.
Probably better, make QgsNewGeoPackageLayerDialog::apply() use
QgsOgrProvider::createEmptyLayer(), and modify that one to reuse an
existing GDALDataset, and no longer call QgsOgrProviderUtils::invalidateCachedLastModifiedDate()
markers tool
Instead of click and hold to rotate, make this tool follow every
other QGIS map tool and use click-click to rotate, click-right click
to cancel.
There's no point showing the full action text in the table, as the table
columns are generally only wide enough to show <20 characters
Otherwise large actions (such as python scripts) can cause huge slowdowns in the
vector layer properties dialog when we try to insert the entire script
into a table cell...
the popup feature menu uses the layer's defined display expression instead
of just showing raw feature ids
This matches the same menu behavior as the identify tool uses
lights aren't separated into distinct tabs
This hopefully avoids the papercut issue where its not obvious
to users exactly which existing lights are in a scene, and also
follows the UI pattern used elsewhere (e.g. symbol layers)
desirable.
By default these errors are logged to the console and in the QGIS UI.
But for some operations errors are expected and logging these just results
in noise.
The code to build the Treeview for the Identify Results is split
in four, for the four different LayerTypes (vector, raster, mesh,
vector-tile).
But although vector and vector tile showed the 'toplevel' in bold
with the layername, the others showed... layer-count and name
in normal font.
This commit changes it so if you use the identify tool in a mixed
layer environment, they look more or less the same...
Just like all other map layer types, meshes CAN have metadata set,
so expose this via a metadata tab in their layer properties window
just like any other layer type.
