Here the idea to create some class to get processing UI more modular,
flexible and more user friendly.
Actually in processing all parameter's widgets are hardcoded in
ParametersPanel, depending on parameter types. This is not flexible to
create custom parameters and related panels.
On top of this, we have a lot of code duplicated between :
Standard algorithm dialog/panel
Batch dialog/panel
Modeler dialog/panel
A more modular vision could be to create a widget class for each
parameter type.
ParametersPanel would only have to iterate over parameters and create
appropriate widgets.
Using this, it could be easy to create new parameter types and related
widgets without creating a custom dialog and panel class for each case.
Proposed design:
Parameter class would have a new "widget" attribute (name as
string) and optionally widget options.
Existing parameters will have a default widget name already given.
Processing UI will maintain a global a registry for widgets (name
=> class)
Each processing plugin could register it's own parameters types and
related widgets.
Each algorithm could override the default widget for a given parameter.
With this design, we have a dissociation between the parameters that are
core related and widgets that are ui oriented. Widgets could be easily
extended without altering the core.
For example, in postgis related algorithms, it could be possible to
create custom widgets, capable of database introspection using existing
GeoDB class to propose drop down lists of schemas and tables or primary
keys and geometry column detection, without altering existing parameter
types.
This is a draft, your comments are welcome.
Arnaud Morvan
Camptocamp
_______________________________________________
Qgis-developer mailing list
[email protected]
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
