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 <wenzesl...@gmail.com> 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 <dr.stevenpaw...@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 >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
