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:
- fix enable state of selected features only after changing between
map layers with/without selections
- fix state of selected features only when running an algorithm
from the history list, e.g. respect original setting for
selected features only (or not)
- ensure no duplicate changed signals are sent, and correctly
emit changed signals in all applicable circumstances
- handle drag and dropped layers from browser panel (UX fix)
- soak with unit tests
Fixes:
- enum parameters set to "allow multiple" only allow a single
value selection when used in modeler
- optional enum parameters cannot be set to no value when
used outside of modeler
Fixes#20406
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
For the c++ api dox this expands to "\c nullptr" (the
\c directive indicates a code literal value), and for sipify/Python
it expands to ``None`` (`` is sphinx annotation for literal values)
Makes for nicer dox for both c++ and Python!
data defined buttons for model child algorithms
The context was not previously exposed, so users would not have
been aware that they can utilise all the variables and functions
available to parameters within child algorithms.
for pre-calculated expressions
Correctly exposes ALL the variables and functions available for use
in pre-calculated expressions so that users actually know they can
use these in their models!
The context contains settings which reflect the context ini
which a Processing parameter widget is shown, e.g., the
parent model algorithm, a linked map canvas, and other relevant
information which allows the widget to fine-tune its behavior.
