<div dir="ltr"><div>Hi Vashek, <br></div><div><br></div><div>Thanks much for all the explanations :)</div><div></div><div>I guess yes, option 2 is fine (not much will change for me indeed). I'll only reinforce the suggestion of the OSGeo4W installer for Windows users in the future. </div><div><br></div><div></div><div>Vero<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié., 9 sept. 2020 a las 5:50, Vaclav Petras (<<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Vero,<br></div><div><br></div><div>I think the question is if a specific workflow is what we are aiming for or if anything that gets users to a terminal+GUI combo is good as long as there is not much work for the user. The issue is that some options are just much more difficult to implement then the others. Or, in other words, the question is what is a sufficient solution.<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 7, 2020 at 7:10 PM Veronica Andreo <<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div>I am ok with not having the terminal when starting grass from an icon, but as Steven, I'd like to have a button to still be able to open the terminal from the GUI. For example, next to the icon for the simple Pyhton editor in the menu bar.</div></div></blockquote><div><br></div><div>Would you still want to have that button there even if that means that it won't be as simple as "Open integrated Python editor" from a user point of view because there will need to be some configuration involved? Or in other words, even if there is a default, it won't work for some people.  Is that still worth it? (See also my email to Steven Pawley for additional details on this.)</div><div><br></div><div>Additionally, as I mentioned in the original post, it seems to me (and I would be happy to be wrong on this) that we might not be able to close some of the terminals. The issue is that we basically need access to the shell started there which might be possible. This might be doable by developing a mechanism to tell GUI about the shell's PID from the shell itself (now we do something like that but are driving that from Python). In any case, it would partially rely on the user configuring it properly (because of the need for configuration).</div><div><br></div><div>One possible way of this is saying we don't care about the prompt, history, and invalid session in this terminal once the main process finishes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>In my case, I teach Grass from the terminal mostly and we use the gui to display results and such. The workflow would then change to open a terminal, call grass --text and then call the GUI with <br></div><div>g.gui... I think that might get even more confusing to students... <br></div></div></blockquote><div><br></div><div>So what about the option 2 then? You open a terminal, type `grass`, hit Enter, and by default you get the shell (because you are in an interactive terminal - that can be detected) and the GUI starts, i.e., exactly what happens now.<br></div><div><br></div><div>Vaclav<br></div></div></div>
</blockquote></div>