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