On Fri, Apr 29, 2011 at 7:31 AM, Julien Malik<[email protected]> wrote:
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.
Yes. Sounds good.
Is this good time to begin laying down this list somewhere ?
I am still trying to keep this thing updated with the insights from
this thread, at least, things I think there is somewhat of a
consensus.
https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework
Anyone is welcome to edit the page.
Any idea about how to handle the 'non Qgis supported' parameters types for
the Python API ?
Keep them opaque. Implementation responsible for supplying python
functions to handle them, if desired.
. 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 ?
Both, but in general signals should be enough, I think. Most
parameters are enumerations, numeric values, etc. after all.
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:
Agreed. GUI on the QGIS side, unless necessary.
Maybe doing band selection and region of interest selection on input rasters
is general enough to be supported by the framework
I was calling the later a "Rect" parameter.
This is a list of parameters I think could be supported by the
framework (much more thought can be put into it, this is just a
starting point):
Raster = OTB Image = SAGA Grid
Vector = OTB vector data = SAGA Shape
URL = OTB File name = OTB Directory name = SAGA FilePath
String = OTB String = SAGA String = SAGA Text = default for
everything not covered
Boolean = OTB Boolean = SAGA Bool
Number = OTB Numeric = OTB Radius = SAGA Int = SAGA Double
Enumeration = OTB Choice = SAGA Choice
Tuple = OTB Origin = OTB Size = SAGA Range
Rect = OTB Region = SAGA Rect
Point = OTB Point/Index = SAGA Point
List = OTB Parameter group = SAGA Grid List, Shapes_List, etc.
(from https://github.com/polymeris/qgis/wiki/List-of-parameters)
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, exactly! I have updated my "mock-up API" to reflect this.
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 ?).
You could actually even remove parameters and add others, change the
state of the module, etc. Everything that is possible in other
contexts. Then fire a signal to tell the framework to re-read what
has changed.
If I'm not wrong, SAGA has this also (it's called Node). Camilo ?
You are right.
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".
This would be implemented like this: Upon change of combobox value the
implementation is signaled and can change its parameters. The
implementation then signals the framework to reread the parameter list
and rebuild the GUI accordingly.
Do you agree with such an approach?
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 ?
See above.
I'm OK with the idea of limiting this to 2 levels max for example (no groups
inside groups).
If we implement parameter groups, there is no reason to limit the
number of levels, IMO, except as a convention to keep the GUI and
Python API more or less usable.
Regards,
Camilo.
