[GRASS-dev] Make terminal window optional?

[Vaclav Petras]

Hi Steven,

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.

On Sun, Sep 6, 2020 at 10:56 AM Steven Pawley <dr.stevenpawley at gmail.com>
wrote:

>
> My 2c is that the terminal should be made as optional because it can
> definitely be confusing and intimidating/off-putting for new users.
>

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


> Apologies if I’ve confused some of the options but here are my thoughts
> regarding the start-up options.
>

I have tried to clarify here and in the email to Paulo van Breugel. Let me
know what parts are still unclear.


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

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?


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

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.


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

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


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

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.

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.


> If the implementation of option (5) is problematic, then I guess mixing
> the startup options by  “grass —gui —shell” to open both the GUI and a
> terminal (like currently) would be possible although it is a bit cumbersome for
> all of the people who routinely punch GRASS commands into the terminal etc.
>

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.

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