[Qgis-developer] QGIS Processing Framework

[Camilo Polymeris]

On Fri, Apr 29, 2011 at 7:31 AM, Julien Malik <julien.malik at c-s.fr> 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.