[Qgis-developer] [Processing] Parameters and widgets refactoring

[Arnaud Morvan]

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 <arnaud.morvan at camptocamp.com>:
>> 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
>> Qgis-developer at lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer