[Qgis-developer] QGIS Processing Framework

[Julien Malik]

Hi !

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

If it does nothing, then it does harm that I'm obliged to inherit from it ;)

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

I'd like that.

> 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.
>
OK for now I think.
>> - 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.
OK I did not understand this part of the code in the first place, now I 
know !
It's me there not being used to all the Python magic yet.

> Open for discussion if you think this is not the best way to handle this.
>
Seems like a good start. I'll give it a try
>> - 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?

I was only mentioning the fact that there is now one part in a plugin, 
and one part in qgis core.
Could there be two plugins ? It will be more easy for others to give it 
a try.

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

This was my point : having a "two way" connection between those.

>> - 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.
>
Will be ok for now.
>> - 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.

I'd love to hear some thoughts from the Qgis gurus about this.

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

Julien