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
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
add an explicit log level getter/setter to QgsProcessingContext which
algorithms can use to determine an appropriate level of feedback
to push to users.
Initially the verbose log only triggers the full verbose output
of model executions (which is also used when running models through
the model designer), but the intention is that more algorithms
will fine tune their output based on the logging level.
qgis_process also gains a new --verbose switch to enable verbose
log output.
When designing a model, users typically will need to run the model
many times as they tweak its structure.
This change causes the parameters used when running the model from
the designer to be remembered and saved into the model, so that
each time you run the model from the designer you don't have to
re-set all the input parameter values to the desired test ones.
Makes iterative model design SO much easier!
Sponsored by Alta Ehf
Only minimal shells of objects are left in Python now, the bare minimum
required because they call objects which depend on Python compatibility
for deprecated API calls...
to handle creation of parameter definition widgets
Previously, these configuration widgets were all hardcoded into the Python modeler
dialog. This prevented 3rd party, plugin provided, parameters from ever being full
first class citizens in QGIS, as there was no way to allow their use as inputs to
user created models to be customised.
Now, the registry is responsible for creating the configuration widget, allowing
for 3rd party parameter types to provide their own customised configuration
widgets.
Refs #26493
And add a Processing setting to allow these to be shown. When shown, they
are highlighted in red with a tooltip explaining that the algorithm
has known issues
