[GRASS-dev] Python scripts receiving input from the GRASS GUI?

[Vaclav Petras]

On Thu, Aug 20, 2015 at 5:49 AM, Michel Wortmann <wortmann at pik-potsdam.de>
wrote:

> I agree that it is a bit of a dirty implementation, but I guess I just
> wanted to make this work quickly.
>

Sure this happens, but we need to avoid that as much as possible. That's
why I was mentioning that there is some refactoring connected to adding new
features - you need to change the code to add new feature seamlessly (and
perhaps to make adding a new one easier) but also fix old mistakes in the
code design (old lack of design :).


> First to your copy-paste solution: I was more looking for something more
> interactive/clickable to precisely avoid the typing/reformatting. Something
> to seamlessly parse a few arguments to existing modules/addons or even
> scripts.
>

In any case, you need to generate nice parseable text in GUI. For example,
context menu in Map Display can give you coordinates which are nicely
formatted for stdin or the coordinates option. Now there is also the button
I mentioned before but the method of coping well formated text from GUI and
pasting in to module GUI (option/field or direct input of file content) is
most general and easy to implement since it requires no coupling. Text
generation and module call are independent. Only the format must be the
same. The disadvantage is that user has to do one additional step. It also
seems that it fits well with the 80-20 rule: with 20% of effort and code
complexity we get 80% of use cases covered.


> Taking on your comments about the non-dependency and sqlite DB issue, I
> will rewrite g.gui.triggers to work with a file in ~/.grass7 and the
> existence of which could then be checked in the dbmgr.base file and the
> gui_core.query file. There could be a 'Launch...' section in the
> right-click menu maybe?
>

Launch... sounds quite general but I'm not sure what exactly would be in
the dialog which would come up?


> I'll update you once I have come that far and maybe you can play around
> with it to see if it's useful for general inclusion.


I'm more and more convinced that you should first try the copy and paste
solution. It has a lot of overlap with what you want to do from
implementation point of view: you have to decide the format, implement the
buttons or context menu items which will create the text (but instead of
calling module, they will put the text into the clipboard) and finally you
have the implement the right input in the particular module you want to
call. Once you have this and you can test it and if it will not be
convincing enough, you can then insert the layer which will couple the two
parts together (Launch... dialog or association specified in ~/.grass7).

Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150820/1ebbe05f/attachment.html>