[GRASS-dev] Make terminal window optional?

Vaclav Petras wenzeslaus at gmail.com
Sat Sep 5 20:05:56 PDT 2020

Dear all,

What do you think about making the terminal window optional?

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

Up until recently, GRASS GIS was not able to start without a terminal.
However, the current master branch can now do that [2]. This gives a new
choice of starting without a terminal because now GRASS GIS detects
presence of an interactive terminal and when it is started from or with
that, it starts the shell otherwise it does not. This makes, for example,
Atl+F2 on Linux desktops work - in that case there is no terminal, so GRASS
GIS starts without that (as opposed to failing as in the past).

We now have these options:

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.

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.

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

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.

Option 1 does not require any further work. Option 2 is mostly a trivial
distribution issue. On Linux it should be one line. I'm not sure about
macOS and Windows. Option 3 is difficult (see below). Option 4 is
relatively simple to implement. Option 5 adds the option 3 difficulties.

Option 3 is difficult to implement because a) there is no cross-platform
way of starting the system terminal application and there is none even for
just Linux (unlike, for example, system web browser for which we even have
a Python package to do that) and b) starting a shell in the terminal with
specific settings is then an additional challenge because a command must be
passed through that terminal application. Hence, the solution needs to make
this customizable so that each user can set whatever works with the given
system, prefered terminal application and shell. Additionally, closing that
newly created terminal or making the exit there close the GUI (as it is
currently done with the shell) may not be even possible.

Let me know which option you like or if you have additional suggestions.

I'm sending this to grass-dev, but if you think this should be cross-posted
on grass-user, feel free to do that.


[1] https://trac.osgeo.org/grass/ticket/3474
[2] https://github.com/OSGeo/grass/pull/768
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20200905/a9674edd/attachment.html>

More information about the grass-dev mailing list