[GRASS-dev] Make terminal window optional?

Tue Sep 8 20:32:59 PDT 2020

Hi Paulo,

I explained better options 3-5 and responded to the rest.

On Sun, Sep 6, 2020 at 6:03 AM Paulo van Breugel <p.vanbreugel at gmail.com>
wrote:

>
> On 06-09-2020 05:05, Vaclav Petras wrote:
>
> 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.
>
> 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.
>
> 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?
>

I hope others will comment on the current state and possibilities on
Windows and macOS.

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.
>
> 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.
>
>
> 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
>

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).

>
> 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.
>
>
> 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.
>

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.

What I meant was everything in option 2, but going with it only in case the
menu entry in GRASS GIS is also available.

>
> 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.)
>
>
> I am not sure I fully understand this option, but if it means one has to
> choose, terminal *or* 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?
>

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.

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.

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.

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.

Update mapset and simplify shell prompts
https://github.com/OSGeo/grass/pull/923

Change the history file according to the current mapset for Bash
https://github.com/OSGeo/grass/pull/930

Close wxGUI on GRASS CLI exit
https://github.com/OSGeo/grass/commit/98e289afa94da6f9aa93953774e4169e9f42f69e

>
> 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.
>
>
> Idem to above
>

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).

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