[Qgis-developer] QGIS Processing Framework

[Camilo Polymeris]

On Thu, Apr 28, 2011 at 11:55 AM, Martin Dobias <wonder.sk at gmail.com> wrote:
> On Wed, Apr 27, 2011 at 6:00 PM, Camilo Polymeris <cpolymeris at gmail.com> wrote:
>> Again, SAGA provides no tag information. It would have to be generated
>> programatically from library/module name & description or provided in
>> a list.
>> Any thoughts on the GUI for that tree? More like SAGA's module tree or
>> more like GIMP's filter menu?
> I would strongly prefer to have the module tree shown in something
> like QTreeWidget - I guess that is what you mean by SAGA's module
> tree. What we have right now is similar to GIMP's filter menu and for
> many users it gets too long and inefficient to use.

Yes. See my "SAGA modules plugin" prototype, where I tried to imitate
SAGA's interface:
http://www2.udec.cl/~cpolymeris/QGIS_Screenshot_04032011.png
Add an editable combo box to the top of the tree, to filter for tags
or names. Maybe a "recently used modules" tree node.


>> I don't think the
>> search/filter/favorites/frequently used part is very hard.. but still,
>> I will keep things simple.
>
> I don't think adding these features would be hard. A very important
> thing in projects like this one is to stay focused on the primary
> target and to keep the scope limited to a reasonable set of features.
> More bells and whistles can be typically added later.

Agreed. I am looking into the WPS thing now. If it is decided that it
would work for us, I would primarly focus on the WPS-SAGA layer. And
secondarily on helping Soeren & Horst with their WPS QGIS plugin.

>> Related topics:
>> * Interactive modules. I had this more or less resolved for SAGA (I
>> think), but designing a more generic solution could prove difficult.
>
> I will try to address these in a follow up to Julien's mail.

Mmm. I was thinking a possible solution would be to handle parameters
through Qt's signal mechanism. Then, the QGIS side could implement
passing values to those parameters from any source, including e.g.
clicks on canvas. Even the state of the plugin (initialization,
runnning, stopped, etc) could be handled as parameter, thus allowing
QGIS to signal the implementation to start, pause, continue, cancel,
etc.

>> * Pushing pipelining to the implementation: Potentially more
>> efficient, but less generic.
>
> As you suggested in other post, the model of executing one module
> after other is completely sufficient (at least for next few years ;-)
>
>> * Undo & redo ability.
>
> Not really necessary, skip it.
>

Ok.

Regards,
Camilo