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
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
