I've started the work to define the common widget interface and
ParametersPanel short methods.
The branch is there :
https://github.com/arnaud-morvan/QGIS/commit/f28898b181e99b082f7f999a8de4d90430349c40
For now this is a draft, openned for discussion.
Not sure I will have a lot of time to spend on this immediately after
the hackfest, fortunately 3.0 is not for next week.
I could take some time to keep it alive, and I will probably have some
time to finish the work in Bonn.
Not sure it will take so much time, the functionnality is there, all to
be done is dispatching code from ParametersPanel to Widgets, and for
sure make some tests and bugfix (specially for batch and modeler dialogs).
Arnaud
Le 28/05/2016 09:00, Victor Olaya a écrit :
I like this design a lot. That will give us a cleaner structure and a
code that is easier to understand.
Definitely this has to be in 3.0, although it will be quite a bit of work.
Any additional comment from anyone?
Arnaud, will you at camptocamp be able to dedicate time to this task?
Let's see how we can better organize it
Thanks!
2016-05-27 18:59 GMT+02:00 Arnaud Morvan <[email protected]>:
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
_______________________________________________
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
