* make QgsMapToolCapture capable of capturing point/line/polygons
This moves part of the code from QgsMapToolDigitizeFeature to QgsMapToolCapture so the tool can actually capture point, line and polygons. It's mainly the 'cadCanvasReleaseEvent` which has been transfered.
* use a current CaptureTechnique in QgsMapToolCapture
QgisApp has been adapted to switch between the different techniques
* add point/line/polygon specific handlers for capture map tool
* convert add part map tool to use QgsMapToolCapture capabilities
* fix use of deprecated methods
* also create a virtual handler for QgsMapToolDigitizeFeature::featureDigitized
* more dox
* use const abstract geom in virtual handlers
* add new class QgsMapToolCaptureLayerGeometry to handle layer specific operation in capture map tool
such as avoiding intersections
* allow to add linear geometries on curved geometry layers
* make actions exclusive
* add settings registry to app
* add a registry for shape map tools
* abstract class for shape map tools
* adapt QgsMapToolCapture to correctly support shape map tools
* clean up of QgisApp
* new class QgsMapToolsDigitizingTechniqueManager to handle actions in app related to capture map tools
* clean up QgisInterface
* sipify
* refactoring of existing shape tools
* refactor add ring to fully support capture map tool
* add missing folder to Doxygen
* fix layout
* fix erasing at iterator pos
* fix unused warning
* fix more dox
* fix cpp check warning
* fix unused warning
* fix annotation map tool does not support shape + set tool name
* correctly handle case when the capture is not done on a vector layer (annotation, mesh, …)
* enable shapes in annotation map tool
* correctly undo and clean
* adapt existing shape tests
the deletion test with circular vertices has been dropped since the capture map tool behaves differently
* fix warning
* refactor fill ring to support shape digitizing
* fix win build
* fix more tests
* avoid detach warnings
* fix app test + clean up
* harmonize new settings with existing ones
* fix categories
* support adding multi lines as a part
* fix adding curve part to multi line
* also handle points
* code a bit clearer
* cast not always valid
* allow adding curved polygon to multipolygon
* add test for QgsGeometry::addPart with curved parts on non-curved geoms (lines and polygons)
* fix with Python < 3.9
* better dox for deprecated interface actions methods
* remove files leftover
* remove leftover circular string curve point tool
* add default Z/M values when calling QgsGeometry::coerceToType
* Apply suggestions from code review
Co-authored-by: Nyall Dawson <nyall.dawson@gmail.com>
* fixes from review
* move layer specific part to specific tool
* fix typo
* fix leak
* fix dox
* fix segmentization
* call map tool implementation of addCurve when adding trace curve to avoid point duplication
* call sub-class implementation
* fix since 3.24 -> 3.26
* fix test
* add test to avoid extra curves when using tracing
* fix headers
Co-authored-by: Nyall Dawson <nyall.dawson@gmail.com>
must be refreshed whenever the item is refreshed
This behaviour is not automatic. The new flag allows items to opt-in,
so that their children WILL be automatically refreshed when the
item is refreshed.
Should be used sparingly only to avoid expensive work
Pass widget as parent to the dialog to avoid "orphaned" child dialogs. The widget is passed as parent to QgsFeatureAction. When creating a dialog the widget is passed as parent to the dialog and the dialog is set as parent to the QgsFeatureAction (last like before).
To avoid confusion with opened dialogs the parent's visibility is set to hidden, when child dialog is opened.
This fixes#47193
accepts the prompt to save the changes BUT then cancels the file dialog
asking for the destination file name, don't treat this as though the
user has opted to discard the model
Specifically, this fixes two issues
1. If a user edits a dark green output block in a model and changes the
name of the output, that new name was always discarded and the only
way to change it was by editing the algorithm it was attached to
2. If an output was renamed through the algorithm properties dialog,
then any properties previously associated with that output (like
comments, coloring, placement, default value, mandatory flag)
would get reset back to their default settings
was a complete match for the old file name, then update the model
name for the saved as model to also match the NEW file name
E.g.
Scenario 1
- user has a model stored as "Save features.model3", named "Save
features"
- user 'saves as' this model as "Delete features.model3"
- the model name is automatically updated to match the new file
name, i.e. "Delete features"
Scenario 2
- user has a model stored as "Save features.model3", named "Process
incoming features from API"
- user 'saves as' this model as "Save features v2.model3"
- the model name is NOT changed, and is left at the original
"Process incoming features from API" name
- When saving a model to a file, don't require that the model already
has a name entered. Instead, if no model name has been entered then
set the model name automatically to match the selected save filename.
E.g. if the user saves the model as "Process incoming features.model3",
then the model name will be set to "Process incoming features".
- When first saving a model, IF the user HAS already entered a model
name then make the default file name suggested by the dialog match
this model name
when configuring a new algorithm
While the previous behaviour of defaulting to a static value makes
sense for things like numeric parameters, this is a very rare use
case for map layer parameters. For better new user experience we can
default instead to showing model inputs for these parameter types.
these are always gracefully caught
Avoids some unwanted "unhandled exception" message boxes which
can pop up while moving the mouse around outside of the valid bounds
of the current map projection
