Re: Make terminal window optional?

Hi Vaclav,

Thanks for taking the time to provide this detailed information.

So, perhaps option 5 is starting to look too complicated, and you are right
that I would probably always start grass from the terminal anyway. So,
option 2 overall looks reasonable.

As a separate PR, I think having a "launch Jupyter" or "new notebook"
button or menu option would be great. Similar to the "simple python editor"
it could serve as a place to include tutorials etc. into python/jupyter
notebook scripting, a little like how Rstudio now has a "tutorial" tab that
launches interactive R markdown tutorials for various data processing tasks.

Steve

On Tue, Sep 8, 2020 at 9:39 PM Vaclav Petras <[email protected]> wrote:

> 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 <[email protected]>
> 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
>

_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev