This new class, QgsBlockingNetworkRequest, is designed for
performing SAFE blocking requests. It is thread safe and
has full support for QGIS proxy and authentication settings.
This class should be used whenever a blocking network
request is required. Unlike implementations
which rely on QApplication::processEvents() or creation of a
QEventLoop, this class is completely
thread safe and can be used on either the main thread or
background threads without issue.
Redirects are automatically handled by the class.
After completion of a request, the reply content should be
retrieved by calling getReplyContent().
This method returns a QgsNetworkReplyContent container,
which is safe and cheap to copy and pass
between threads without issue.
The guts of this class have been copied from QgsWfsRequest (which
has been using the same approach since 3.2)
Encapsulates a network reply within a container which
is inexpensive to copy and safe to pass around between threads.
The default Qt QNetworkReply class is a QObject, which prevents
it from being copied and passed between threads. This class
grabs all the useful information from a QNetworkReply,
allowing the reply's content to be stored indefinetly without
concern for the lifetime of the QNetworkReply object itself.
This feature allows other layout items (such as scalebars,
north arrows, inset maps, etc) to be marked as a blockers for
the map labels in a map item. This prevents any map labels from
being placed under those items - causing the labeling engine
to either try alternative placement for these labels (or
discarding them altogether)
This allows for more cartographically pleasing maps -- placing
labels under other items can make them hard to read, yet without
this new setting it's non-trivial to get QGIS to avoid placing
the labels in these obscured areas.
The blocking items are set through a map item's properties, under
the label settings panel. The setting is per-map item, so you can have
a scalebar block the labels for one map in your layout and not others
(if you so desire!)
is called on non-single-polygon geometries
Previously we would just return an empty list when geometries of invalid
type were used, but this is dangerous and we are safer to explicitly
raise errors preventing use of asPolygon() with incompatible geometry types.
Also avoid massive long __repr__ strings for complex geometries,
as these can flood the Python console (and first aid plugin),
and aren't useful for debugging anyway.
Refs #14640
should show partial labels
Layout map items no longer respect the default project setting
for "show partial labels", and instead have their own, per map
setting for this option. (Under the map item properties,
labeling settings button).
The map item setting always defaults to off (unlike the canvas
setting, which defaults to true for a new project) as layouts
should always default to the settings which produce the highest
quality cartographic outputs.
In general I suspect that most users would always want to avoid
rendering partial labels in layouts, but this setting was
previously so deeply hidden that most are unaware of how to
change it. (And previous discussion about changing the canvas
setting to hide partial labels deemed this default undesirable
for the canvas, where showing even a small part of a label
on the map border can help identify what sits just on/off
the edges of the map)
a toolbar in the map item properties panel
This moves the
- refresh preview
- set to map canvas extent
- view extent in map canvas
buttons from being oversized push buttons within the item properties
panel up to a new toolbar at the top of this panel. Apart from looking
better, it means these important actions are always visible regardless
of the scroll position of the item properties panel itself.
Additionally, it makes it possible to add MORE actions here without
overloading the UI (e.g. "set canvas extent to item extent")
TODO: better icons
is called on non-single-line geometries
Previously we would just return an empty list when geometries of invalid
type were used, but this is dangerous and we are safer to explicitly
raise errors preventing use of asPolyline() with incompatible geometry types.
This setting allows per-map control of how close labels are permitted
to be placed to the map item's edges.
Sizes can be set using mm/inches/pixels/etc, and data defined
label margins are allowed.
Fixes#10314
This controls how close labels are permitted to the edges of the map
item. The labeling engine will then try other candidate positions
in order to avoid placing labels within this margin.
in QgsMapSettings to restrict where labels are allowed to be placed
within.
If set, this overrides the default behavior of allowing labels to
be placed anywhere inside the rendered map extent.
multipoint datasets
There's no single approach to use for multi-point inputs, so instead
of overloading this algorithm with extra options to control how these
are handled, we raise a helpful error and push the reponsibility back
to the user to get the data into the right format before running the
tool.
Fixes#20799
This adds a new available parameter type for processing algorithms,
QgsProcessingParameterAuthConfig, allowing selection from available
authentication configurations (and creation of new ones).
It allows creation of processing algorithm which can fully take
advantage of QGIS' mature authentication handling, avoiding the
need to use insecure string parameters for users to input
sensitive logon credentials.
QgsProcessingParameterAuthConfig parameters are evaluated using
QgsProcessingAlgorithm.parameterAsString(), which returns the
selected authentication configuration ID.
is called on non-single-point geometries
Previously we would just return QgsPointXY(0,0) when geometries of invalid
type were used, but this is dangerous and we are safer to explicitly
raise errors preventing use of asPoint() with incompatible geometry types.
And replace labeling engine dialog "Draw text as outlines" checkbox with a combobox
presenting the choice of always rendering as outlines OR text.
(This will allow us to easily add additional methods in future, e.g. potentially
a "Render as text wherever possible" setting, for defaulting to text objects
whenever it doesn't impact the rendering quality to do so)
The new QgsRenderContext::TextRenderFormat enum controls how text
should be handled during a render operation, e.g. whether to render
text as outlines (paths) or keep it as real text objects.
Deprecate previous arguments in QgsTextRenderer which handled
this same use case.
This allows us to make the setting vary per-render, instead of
having a single global flag controlling the setting. Ultimately
this will allow us to have different behaviour within the
canvas renders vs print layout exports.
Refs #3975
