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