<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 20, 2015 at 5:49 AM, Michel Wortmann <span dir="ltr"><<a href="mailto:wortmann@pik-potsdam.de" target="_blank">wortmann@pik-potsdam.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">I agree that it is a bit of a dirty implementation, but I guess I
    just wanted to make this work quickly.<br></span></blockquote><div><br></div><div>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 :).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
    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.<br></span></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
    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?<br></span></blockquote><div><br></div><div>Launch... sounds quite general but I'm not sure what exactly would be in the dialog which would come up?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
    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.</span></blockquote></div><br></div><div class="gmail_extra">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).<br><br></div><div class="gmail_extra">Vaclav<br></div></div>