<div dir="ltr"><div>Hi Paulo,</div><div><br></div><div>I explained better options 3-5 and responded to the rest.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 6, 2020 at 6:03 AM Paulo van Breugel <<a href="mailto:p.vanbreugel@gmail.com">p.vanbreugel@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>
<p><br>
</p>
<div>On 06-09-2020 05:05, Vaclav Petras
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>When you start GRASS GIS now, it always also starts with a
system terminal window which has a shell which has modified
prompt and history. What I'm proposing is to make this opt-in,
i.e., a user will have to take an action in order to get this
terminal.</div>
<div><br>
</div>
<div>If there is no terminal by default, only users who actually
want that will get it which means that the users who don't ask
for it don't have to wonder what that is or what is the
relation between terminal and GUI. This may clarify some of
the first-time user confusion such as "once i open the grass
gis console...it opens another application called layer
manager" [1]. For those who don't use the terminal, this would
also simplify all the exit and switch mapset situations such
as "Close GUI" versus "Quit GRASS GIS". Users starting GRASS
GIS from a terminal won't be affected by it. Users who want to
use GRASS GIS from terminal could just start GRASS GIS from
terminal.<br>
</div>
</div>
</blockquote>
On my Windows computer, I have installed GRASS using OSGeo4W.
OSGeo4W comes with a shell from which I can start grass. Is that
true for the stand alone installer as well?<br></div></blockquote><div><br></div><div><br></div><div>I hope others will comment on the current state and possibilities on Windows and macOS.</div><div></div><div><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>
<blockquote type="cite">
<div dir="ltr">
<div>
</div>
<div>
</div>
<div>1. Have terminal started when GRASS GIS is started from a
desktop launcher such as the Start menu on Windows. This is
the current behavior in 7.8 plus the fix of requiring a
terminal if it is not present, i.e. in cases such as the
Atl+F2 on Linux, you will get GRASS GIS without a terminal.<br>
</div>
<div><br>
</div>
<div>2. Remove the terminal from desktop launchers so that GRASS
GIS starts without the terminal when started in the GUI way.
When a user starts GRASS GIS using a command from an existing
terminal, there is no change from the current behavior: a
(sub-)shell is started and possibly GUI launches.<br>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>This would be my (strong) preference, serves both experienced
users who like to work from the terminal and novices well. The
fact that it doesn't take much work is a bonus <br></p></div></blockquote><div><br></div><div>I like this one too. It is quite doable and it seems natural. You start from the "system GUI", you get a standard GUI application. You start from the terminal, you get both as you are getting now (and can disable the GUI if you want to with --text).<br></div><div></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><p>
</p>
<p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>3. The same as option 2 (no terminal from desktop
launchers, shell from terminal), but only when the GUI will
allow to start a terminal application using a menu entry.<br>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Not sure I understand this option - you mean to say that one can
only start the terminal from the GUI? If so, I don't see the
advantage of this option.</p></div></blockquote><div><br></div><div>Well, that would be an option. It would then behave like RStudio or VS Code (see, e.g., Steven Pawley's email) which you could count as an advantage.</div><div><br></div><div>What I meant was everything in option 2, but going with it only in case the menu entry in GRASS GIS is also available.<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><p>
</p>
<p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>4. Make the shell start only in the text mode (grass
--text) or with a new additional option (--shell), i.e., you
get it, only when you actually ask for it. In other words,
with --text, GRASS GIS would behave more like R or Octave,
without that (with --gui), it would behave more like QGIS or
any other GUI application. (This includes the no terminal from
desktop launchers from option 2.)<br>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>I am not sure I fully understand this option, but if it means one
has to choose, terminal <u>or</u> GUI, I would be very much
against this option. I very often use both (and often enough in
combination with R starting from the command line). I know I could
use the console, but I don't find that near as convenient as
working from the terminal. And what would be the added value of
this option?<br></p></div></blockquote><div><br></div><div>You would not have to choose one or another as you can start GUI from the terminal with g.gui. The Console in GUI cannot run an interactive program like R, so that would not suffice, but starting a shell only is perfectly good for starting GUI, R, or both afterwards.</div><div><br></div><div>It also does not mean you cannot ask for both. Closest to the current implementation is --text starts only shell while --gui starts only GUI, but you could also allow combining these two to start both or have additional --shell which starts the (sub-)shell even when --gui was provided.<br></div><div><br></div><div>The nice thing about this option is that it doesn't do anything unexpected. It is not trying to guess that the user may want to use the terminal. It starts GUI with one option combo (and by default) and a (sub-)shell with another (or possibly both with yet another combo). From a slightly different point of view, it puts the two behaviors into two categories, with --text GRASS GIS is a command line application like R or Octave, with --gui, it is a GUI application like QGIS or RStudio with not much happening in the terminal.</div><div><br></div><div>If (additionally) combining --text and --gui is not allowed, it removes all problems of syncing between GUI and the shell which needs to be partially implemented in the shell and that is different for each shell. See e.g. the PR and commits below, but there is more.</div><div><br></div><div>Update mapset and simplify shell prompts</div><div><a href="https://github.com/OSGeo/grass/pull/923">https://github.com/OSGeo/grass/pull/923</a></div><div><br></div><div>Change the history file according to the current mapset for Bash</div><div><a href="https://github.com/OSGeo/grass/pull/930">https://github.com/OSGeo/grass/pull/930</a></div><div><br></div><div>Close wxGUI on GRASS CLI exit</div><div><a href="https://github.com/OSGeo/grass/commit/98e289afa94da6f9aa93953774e4169e9f42f69e">https://github.com/OSGeo/grass/commit/98e289afa94da6f9aa93953774e4169e9f42f69e</a></div><div> </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><p>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>5. The same as option 4 (shell only with --text or
--shell), but only when the GUI will allow to start a terminal
application using a menu entry as in option 3.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Idem to above<br></p></div></blockquote><div><br></div><div>All from option 4, but combining --text and --gui is for sure allowed and we would follow with this only when starting terminal from GUI is possible (like in option 3). </div><div><br></div><div>Vaclav<br></div></div></div>