[Qgis-developer] QGIS Processing Framework

[Julien Malik]

Hi all,

Reading a thread on qgis-users from yesterday ("Sextante library"), I 
discovered the existence of a Python library called Traits : 
http://code.enthought.com/projects/traits/

I read 
http://code.enthought.com/projects/traits/docs/html/tutorials/traits_ui_scientific_app.html
and came out with a "Are we reinventing the wheel ?" feeling.

Has anybody some experience in using this library ?
Is it usable in QGis (it already has a PyQt GUI backend) ? Any 
limitation coming to mind ?
Could it be the background on which the QGis Processing Framework is built ?

I don't know at what point it can be customized, if it will fit to all 
the requirements, but it surely adresses the same needs.

Julien



Le 29/04/2011 17:54, Camilo Polymeris a écrit :
> 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.
>