[Qgis-developer] QGIS Processing Framework

[MALIK Julien]

Hello,

Here are some remarks :

- It's good to have deleted the Library class. I had no use of it.  
This makes the code much more simpler.

- Is the Plugin class really necessary ? It does nothing now. Maybe  
it's better to remove it also, so each plugin can do what he wants  
during the import (maybe also create a specific gui for its own  
"general configuration"). The only thing important to be a "processing  
plugin" would be to register itself to the framework during initGui()  
and deregister itself in unload(). I think it would be more coherent  
with the way Qgis manages plugins (you could more easily  
enable/disable one of the implementations in the plugin manager,  
probably better for updates too)

- I think a lot currently happen in the constructors and during the  
different module imports (loading of all the modules with their  
description/params/etc), and it would be good to lower it down.
Currently we register "modules" to the framework.
Could we instead register one main object which can be queried for a  
list of available modules (their names, description, tags, docs,...),  
for a list of general info to keep track of its provenance (is it  
"Saga", "OTB", ..., so that the framework knows easily how to  
differenciate them), and can create actual ModuleInstance on demand ?  
The idea would be that the framework ask things to the different  
implementations when it needs to, and not the other way around (as it  
is a singleton, i think it is safer that way)
Also, IMHO the details of the different parameters of a module should  
not be taken into account as long as we don't create an instance of  
this module.

- about the gui part : should it be possible to create the specific  
widget for a parameter for which the framework does not provide a  
default ? i think so. Maybe it would make sense that each  
ModuleInstance can be queried for the widget, a default implementation  
being provided for all standard types. Even for the standard provided  
widgets, it could be nice to be able to simply subclass them to add  
our own things (not sure about this).

- is there a need for keeping 2 modules (processing and  
processingplugin) ? can a plugin depend on another plugin (in my otb  
plugin can I "import processingplugin") ? if yes, putting everything  
in one plugin will make it more easy to distribute a version of the  
code (as long as it is python...).

- the panel should be more tied to the framework singleton : when a  
new plugin is loaded/unloaded, it should be possible to update the  
Panel for example (putting the gui initialization outside of the Panel  
constructor may help)

- the panel does not provide an easy way to differenciate between the  
different implementations (saga/otb...). Maybe a tag could be used for  
it, or maybe it should be given a different meaning (like the "main  
tag"). For later, you might want to add an easy way to enable/disable  
all the OTB/Saga/Gdal/ by just clicking on an icon ?

- I/O : how will this be handled ? I'm asking this related to the  
recent mails with interest for providing ossim image chains in Qgis.
If it must support module chaining, then there is a need for an  
abstraction of the i/o mechanism. is it the qgis dataproviders ? a  
module can take a raster/vector dataprovider as input and can output a  
raster/vector dataprovider ?

Keep up the good work !
Julien


Quoting Camilo Polymeris <cpolymeris at gmail.com>:

> Applied your patches to my repo, Julien, thanks a lot!
>
> What is your opinion on the function of the "QGIS Processing *plugin*"
> -- just showing the panel? Or should perhaps everything gui-related be
> moved into the plugin? Is it really necessary, couldn't the framework
> singleton could just register the panel & associated menu items?
>
> I intend to soon publish a prototype of the plugin(s) on the faunalia
> repo, so that we'll hopefully have more feedback.
>
> Regards,

> Camilo
>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.