- fix parameter can get converted to plain number parameter after edits
- allow parameter to be linked to parent parameters, so that the
correct distance unit and choices are shown for the parameter
This setting, which is disabled by default and placed into an
"advanced" group on PDF/SFG export, disables the built-in
raster layer tiled rendering. While the tiling is good for
memory usage, it can cause visible "seams" in the rasters
for generated PDF/SVG files.
The setting has a tooltip warning users that disabling the
tiling results in high memory usage during exports.
Fixes#19500
of main algorithm
Using code like:
buffered_layer = processing.run(..., context, feedback)['OUTPUT']
...
return {'OUTPUT': buffered_layer}
can cause issues if done as a sub-step of a larger processing algorithm. This
is because ownership of the generated layer is transferred to the caller
(Python) by processing.run. When the algorithm returns, Processing
attempts to move ownership of the layer from the context to the caller,
resulting in a crash.
(This is by design, because processing.run has been optimised for the
most common use case, which is one-off execution of algorithms as part
of a script, not as part of another processing algorithm. Accordingly
by design it returns layers and ownership to the caller, making things
easier for callers as they do not then have to resolve the layer reference
from the context object and handle ownership themselves)
This commit adds a new "is_child_algorithm" argument to processing.run.
For algorithms which are executed as sub-steps of a larger algorithm
is_child_algorithm should be set to True to avoid any ownership issues
with layers. E.g.
buffered_layer = processing.run(..., context, feedback, is_child_algorithm=True)['OUTPUT']
...
return {'OUTPUT': buffered_layer}
For algorithms with multiple parameters depending on a vector layer parameter, the code that loads the layer in the background is called repeatedly, impacting performance. A small layer cache is implemented with these changes, so the dialog only tries to load the layer once.
SSL error occurs in non-main thread
This commit reworks how SSL errors are handled in QGIS. Previously,
ssl errors emitted by non-main thread QgsNetworkAccessManager instances
were handled by the main thread in QgisApp on next event loop. But
app (in the main thread) tried to pause the timeout timer for the
QNetworkReply containing the error, which doesn't work, because you
can't stop a timer in the main thread for a timer object created
in another thread. This meant that the reply could get deleted in
the background thread while the main thread was still using it
and waiting for users to respond to the SSL error. Now the timer
handling is done in the background thread's network access manager
instance, so in the thread matching the reply's timeout timer. We
then have to do some fancy thread locking using QWaitCondition,
because we need to "pause" that thread until the SSL error
is handled in the main thread -- if we don't pause the background
thread, Qt immediately resumes the QNetworkReply without ever
giving us the change to ignore ssl errors in the reply. Phew!
Additionally, the previous approach had a shortcoming in that
there was no way to notify background threads that ssl errors
had actually be handled. To do this we need a new signal which
can be fired after app has shown the ssl dialog and given users
a chance to respond. BUT... we can't safely do this -- if we
add a method to notify background threads when ssl errors have
been handled, then it CANNOT safely reside in app -- doing so
would break for QGIS server and QField etc, where theres no
app instance around to provide this notification. As a result
I've abstracted out the ssl error handling. By default there's
a simple error handler which just logs errors and returns
without ignoring them (i.e. default Qt behavior, an ssl error
cancels the request). App has a specific subclass of the ssl
error handler which presents the nice dialog and asks users to
choose what to do. Potentially server could decide to make
its own subclass too, which could e.g. ignore SSL warnings
if an environment variable is present (but at the moment
the behavior is effectively unchanged for server).
The end result is that SSL error handling should now be
totally thread safe, and we shouldn't hit any more deadlocks
and crashes when ssl errors occur in background threads.
I've also taken the opportunity to add a new signal which
is always emitted by the main thread QgsNetworkAccessManager
instance, which is emitted whenever ANY request on any
thread encounters an SSL error, and contains the requestId
so that the ssl error can be linked back to the originating
request. This is for debugging, and for use by the
network monitoring plugin to show ssl errors encountered
by requests.
And allow these to be retrieved from QgsNetworkRequestParameters.
This allows logging code to identify the area of code where a request
originated from, making debugging much easier!
Tag all requests created with appropriate class name and IDs
This signal is propagated to the main thread QgsNetworkAccessManager
instance, so it is necessary only to connect to the main thread's signal
in order to receive notifications about requests created in any thread.
Also includes the original requestId to allow linked download progress
to original request
internal symbol clones
Rendering symbols is a NON-CONST operation, which can permanently
alter the symbol instance (e.g. via changes made by the symbol
or symbol layer's startRender methods.).
This makes debugging super complex - because methods which look
like they are just generating previews of symbols can actually
change the original symbol instances, resulting in permanent changes
to a layer's style.
Refs #19910 (specifically, me pulling my hair out trying to deduce
seemingly random changes to layer's symbols)
Instead of requiring clients to generate temporary file names themselves,
(or use the cryptic "memory:" string!), this PR adds a static constant
QgsProcessing.TEMPORARY_OUTPUT
If a layer/sink output parameter is set to QgsProcessing.TEMPORARY_OUTPUT,
then the temporary output filename will be generated automatically at
algorithm run time. This means callers don't need to mess around with
finding appropriate temporary folders and paths.
Another benefit is that TEMPORARY_OUTPUT is stored in the processing
history, so if you re-run a previous algorithm which was set to
output to a temporary file, it no longer tries to use that same
previous temporary path and instead generates a new one.
This PR continues the work started in PR #8951.
This commit replaces occurences of #include "qgis.h" by #include "qgis_sip.h",
where possible = when files only depends on SIP_XXX features.
use with ArcGIS feature server requests
Some servers are locked down to only allow requests with a specific
referer URL - this allows us to open them in QGIS (but it requires
users to manually determine the correct referer string and populate
this setting for the connection -- we cannot do this for them!)
This algorithm cannot output cross-validation results and topographic
parameters simultaneously, hence two tools needed. Thanks to Pedro Venâncio
for finding this and proposing a fix.
