<div dir="ltr"><div>Hi Steven,</div><div><br></div><div>You brought up several good points. I tried to cover all of them in my answer, but some may need more discussion. Hopefully, I was able to clarify some of my points.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 6, 2020 at 10:56 AM Steven Pawley <<a href="mailto:dr.stevenpawley@gmail.com" target="_blank">dr.stevenpawley@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><div><br></div><div>My 2c is that the terminal should be made as optional because it can definitely be confusing and intimidating/off-putting for new users.</div></div></blockquote><div><br></div><div>Right, I think that's because people who don't want to use the command line, get it anyway. What I like about the options 2-5 is that they leave the choice to the user either automatically based on use of terminal (options 2 and 3) or explicit from command line parameters (options 4 and 5).<br></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><div><font color="#000000"><span>Apologies if I’ve confused some of the options but here are my thoughts regarding the start-up options.</span></font></div></div></blockquote><div><br></div><div>I have tried to clarify here and in the email to Paulo van Breugel. Let me know what parts are still unclear.<br></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><div></div><div>Unfortunately (in terms of complexity) option 5 would my preference. I like what it inherits from option 4, in that “grass —text” would always start with a terminal and just “grass” will *always* opens the full desktop application/GUI.</div></div></blockquote><div><br></div><div>I like that this makes GRASS GIS fall into clear categories of GUI app and shell one at a time, not both at the same time, but see my comments at the end of this email. When I'm typing "grass" in an interactive terminal, do I want to get only the GUI as a GRASS GIS user who is clearly also a command line user?<br></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><div></div><div>However, once in the GUI, ideally you would be able to launch a terminal session from a menu option, e.g. a bit like Rstudio or VScode.</div></div></blockquote><div><br></div><div>The PR which was adding or fixing "open terminal" for VS Code looked like a struggle, basically the same conclusion I made: you need user customization to make it robust enough. GRASS GIS has additional complexity. I assume that people expect to get a specific prompt and history like what you have in the terminal.<br></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><div>This is obviously how you want to launch an R or Jupyter session, and it was be unfortunate to have to exit GRASS and restart a session with a terminal just to do this.</div></div></blockquote><div><br></div><div>If you are the type of user starting R and Jupyter sessions aren't you already in a terminal to run GRASS GIS from there? On the other hand, starting R, RStudio, or perhaps even Jupyter could be nicely supported by this "run custom application in the current session from GUI" feature (which is what makes options 3 and 5 a lot of work to implement).<br></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><div> Also, what happens when the GRASS GUI crashes and you are not running a terminal? One of the aspects that I really like about GRASS is that even if any particular component of the application, like the GUI crashes, the session continues and modules/scripts keep on running, so everything is usually recoverable.</div></div></blockquote><div><br></div><div>Well, what happens now? What is running from the GUI should end with the GUI. If you are used to center your workflow around the terminal and you would start GRASS GIS from a terminal starting the (sub-)shell (--text, --shell, or options 2 and 3), nothing really changes. What you started from the terminal, still runs after a GUI crash. Your already written maps are fine. In the pure GUI scenario, you get to the mapset after breaking the lock.</div><div><br></div><div>If you would like to have that recovery even in the pure GUI scenario, that would be possible. GUI is currently started from another process which could restart the GUI on failure as long as we can detect it. That's a related, yet separate feature.<br></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><div></div><div><font color="#000000"><span>If the implementation of option (5) is problematic, then I guess mixing the startup options by </span></font><span style="color:rgb(0,0,0)"> </span><font color="#000000"><span>“grass —gui —shell” to open both the GUI and a terminal (like currently) would be possible although it is a bit cumbersome </span></font><span style="color:rgb(0,0,0)">for all of the people who routinely punch GRASS commands into the terminal etc.</span></div></div></blockquote><div><br></div><div>This "--gui --shell" you describe is similar to the option 2 (and 3). In that case, the --gui is the default (until you use --text) and is forced when started without a terminal (i.e., from menu/icon/launcher). The "--shell" piece is determined automatically based on you being or not being in a terminal. In that case, grass command is basically guessing that when a user runs that from an interactive terminal, that user also wants a (sub-)shell in a current GRASS GIS session.</div><div><br></div><div>Vaclav<br></div></div></div>