[Qgis-developer] QGIS Processing Framework

[Julien Malik]

Hi Martin !
> The point is actually not to provide every possible parameter type in
> the framework. IMO we should have a base "parameter" type with several
> common types such as integer, string, vector layer, enumeration. Such
> types are used widely and QGIS would come with default edit widgets
> for them.
>
> Then, each library might require some additional parameter types that
> might also require special editing widgets. The plugin implementing
> support for such library will provide these types and editing widgets,
> however they will stay opaque for QGIS. So in the result QGIS will
> just know there is a parameter and it will know what widget to show in
> the form, nothing more. Of course such custom types would not be
> usable across various libraries, but that fine.

OK, it seems a good balance.
Is this good time to begin laying down this list somewhere ?

Any idea about how to handle the 'non Qgis supported' parameters types 
for the Python API ?


> . Here QGIS would provide
> default GUI for a module based on the description, with the
> possibility for the developer to improve the basic behavior using Qt
> signals and slots for a better user experience.

Are signals and slots sufficient ?
Maybe being able to provide a subclass of the default Qgis supported 
widgets would be cool ?

> Therefore I tend to think about the whole procesing framework in two levels:
> 1. backend - similar to WPS: an interface for description of modules,
> querying the modules and running them
> 2. gui - built on top of the backend, enhancing the usability and
> experience for the user:
>
> In the GUI part there are endless possibilities how to improve the
> experience: the developer might want to add a preview for a module
> that does some raster processing. Or the developer might add
> interactive rectangle selection from map canvas for choosing a region
> of interest for the analysis.

Maybe doing band selection and region of interest selection on input 
rasters is general enough to be supported by the framework

>
> I completely agree that many times the dependencies between the
> parameters are far too complex to be modelled in a declarative way. I
> hope my answer above clarifies this: you as a developer of the
> orthorectification module would be allowed to watch for changes in the
> form (using Qt signals) and update other parameters - or do whatever
> you want.
>

Yes it's more clear.
We should consider not only being able to update the parameters values, 
but also the GUI part (changing some widget settings, eventually even 
changing the widget class somehow ?).


>> [5]
>> The model we imagined for the parameter list will be a tree more than a flat
>> list.
>> A group of parameters is just one node of the tree, containing a parameters
>> list, where each parameter can also be a group of parameters.
> Well, I'm a bit afraid of trees of parameters. Would that be really
> necessary for OTB?
>

Don't worry too much, we are not planning to have 42 nested level of 
parameters...

Having "groups" of parameters is a need.
If I'm not wrong, SAGA has this also (it's called Node). Camilo ?

Also we want to have parameters shown only depending on a combobox 
value, for example.
So a choice parameter value is declared with both what to show in the 
combobox, and an associated "parameter group".
Please see at the end of 
http://wiki.orfeo-toolbox.org/index.php/OTB-Wrapper.
If in this group you have another choice parameter, you end up with a 
tree...

If you have a good idea to model that in a simpler way, I'll take it.
Flat parameter model, but the GUI can rearrange/show/hide them dynamically ?

I'm OK with the idea of limiting this to 2 levels max for example (no 
groups inside groups).



Best regards,
Julien