Something internal in KDE itself adds child QObjects to menus, so the
code which tries to find the last action in the menu fails and returns
a QObject instead of a QAction, leading to an exception in the
insertAction call.
This is all too fragile anyway, so avoid it by:
- Just creating the models menu directly in the ui
- Exposing this via interface for use in the processing plugin
Now there's no risk of this code breaking in future if the Project
menu is re-arranged.
this has been done automatically with the following comand line
./scripts/3to4/3to4.py --only-qgis3-compatible-changes ./python/plugins/
./scripts/3to4/3to4.py --only-qgis3-compatible-changes ./tests/src/python/
provider loading until after ALL plugins have been loaded
This avoids the model provider from refreshing all the model
algorithms multiple times, once for each non-default plugin installed
which implements a processing provider.
Instead of forcing all steps in the batch processing dialog to execute
in the main thread, we now run each step as a separate task whenever
possible. This keeps the UI nice and responsive, and permits
responsive cancelation and progress reporting.
Individual steps are still run sequentially, not in parallel (yet!)
No user visible changes, but we gain the flexibility for better
history storage, including the ability to store the outputs
calculated by the algorithm execution...!
- Make the new Temp Folder setting optional, default to an empty
string, and note that empty = use default
- Move responsibility for cleanup of temporary folders to c++ (if
Processing Python part crashes, or doesn't exist, then we still
want these cleaned up correctly)
Invalidate the locator results when active layer changes
Fix#20099 - Locator bar does not update the filter of algorithms according to active layer when using "ef"
If the active layer is not editable, the executor will
try to switch editing on.
If there are no selected features, the executor will
select all features before running.