[Qgis-developer] QGIS Processing Framework

[Camilo Polymeris]

On Mon, Jun 13, 2011 at 10:15 AM, MALIK Julien <julien.malik at c-s.fr> wrote:
> Hello,

Hello, Julien.
You bring up some very important points.

> 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)

Yes, you are correct, the processing.Plugin class does nothing -- does
no harm either, but agree on removing it.

> - 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.

Also remove the arguments from the processing. Module constructor, and
have e.g. saga.Module override paramters(), name(), tags(), etc, so
that the relevant code only gets executed when necessary.
Each plugin would then be responsible for registering/deregistering
it's modules. Either passing a list or a callback to the framework.

On the provenance: I just had the saga implementation add a 'saga' tag
to every module. I think that's the simplest solution. It doesn't show
up currently, because, every module having that tag it is deemed
irrelevant by the framework.

> - 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).

Implement parameter.widget(value) in a subclass if you want custom
widgets. That function should get called by
processingplugin.Dialog.widgetByType(), if present. Haven't tried it
yet, though.

Open for discussion if you think this is not the best way to handle 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...).

But, YOU introduced 'processingplugin'! :D

I think it is a good idea to keep them both: QGIS plugins are
inherently GUI-related, they have a initGui method, after all. But,
the QGIS processing framework should work in a GUI agnostic way, so
that it will be useful in other environments, too. Having processing
for the logic & processingplugin for the GUI, forces us to keep both
aspects separated.

Perhaps the names are too similar, confusing... rename
processingplugin to processingPanel or processingGUI or something?

> - 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)

I am not sure of what you mean: I precisely tried to separate the
framework from the panel. What would be A Good Thing, I think, is
reimplementing the panel with QTreeView and the framework as a
ItemModel. That way the panel would get updated whenever the framework
changes.
What do you think?

> - 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 ?

Agree: tags. Standard tags for now, I think. If we see the need to
introduce 'special tags' we can always do that later.

> - 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 ?

Yes, qgis dataproviders, I think. Perhaps alternatives later. This is,
IMO, one of the most dificult aspects remaining to define.
Note that I had defined 'roles' for parameters: input, output &
option, feedback.
Input & output would contain dataproviders, while option & feedback
contain other variables, e.g. integers, strings, etc. The later are
read-only from the frameworks point of view, just a way to pass
messages or simple results to the user.

There also is the special 'state' option paramter, which controls the
ModuleInstance's, well, state (running, paused, stopped, etc.)

> Keep up the good work !
> Julien
>

Merged your fixes, btw. Thanks!

Camilo