Instead of the confusing duplicate settings for foreground color
vs cell text color, remove the foreground color button and only
expose this color setting via the cell text color.
extent and have had to resort to fetching all features from a layer,
defer the geometry clipping the map extent so that it occurs
AFTER transforming the layer's geometries to the target map extent.
This allows us to correctly clip the feature geometries in the case
that the visible extent available from the render context for the layer
is not accurate (i.e. it's a whole of globe fallback), and avoids
rendering features which fall far outside of the visible map
region.
Fixes#38878
Only recalculate the position of the icons for affected legend nodes.
Avoids brute forcing over complex legends as soon as something is changed.
Fixes#38890
update 'the' to 'then' on line 34
update 'customwidget' to 'custom widget' to match reference in comment on line 72
Update 'windows' to 'Windows' on line 65 to match previous reference on line 31
Fixes#38092 by adding an optional QgsFeedback argument to
the executeSql method and by implementing the PQCancel
method in the PG provider internals.
While the cancellation works well for all supported provider while
fetching results in the loop, the cancellation of a running query is now
implemented for the postgres provider connection only because the GPKG
and GDAL both rely on GDALDatasetExecuteSQL which cannot be interrupted.
This PR also introduce a few optimizations in the PG DB-Manager
code that should probably fix also other "slowness" issues that
were reported after 3.x during PG query execution.
A small UX change in th SQL dialog makes it evident to the user that
a cancellation request has been sent to the backend: the button text
is changed to "Cancellation requested, please wait..." so that for
provider connections that are not able to interrupt the running query
and must wait for the fetching loop to exit from the exeuteSql call
the user knows that something is happening and that a cancellation
request has been successfully sent.
This prevents the Python GIL from being released before calling the method
(which is the default behaviour). For very cheap to call c++ methods the
cost of releasing the GIL can outweigh the cost of the c++ call, which means
it's more efficient to retain the hold on the GIL.
Ideally we'd do this everywhere, and switch to an explicit ReleaseGIL
annotation on functions which are slow or risky (raise exceptions, or
do something which can cause a GIL deadlock). But those are very tricky
to identify, so instead just explicitly hold the gil on cheap methods
which are likely to be called many times and could have an impact on
script performance.
are to be clipped from the project, instead of just tracking this
by the presence of any checked layers
Avoids inconsistencies between the layers which are visibly clipped
on the map vs the options which are set in the GUI.
