Re: [GRASS-dev] Make terminal window optional?
Hi Vaclav, Thanks for the detailed response. I would still have a preference for option 2, it being relative ease to implement, and providing both a startup with and without command line. But all options have their merits for sure. Cheers, Paulo On 9-9-2020 05:32, Vaclav Petras wrote: 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 mailto:p.vanbreu...@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
Re: [GRASS-dev] Make terminal window optional?
Hei, Not strictly limited to the details in this discussion, but somewhat related: Having the terminal as an “opt in” sounds reasonable to me, esp. with the new UI/startup design. Experienced users can always start terminal deliberately. And if user prefrences can still get picked up from the .grassrc file that would be nice. So, even if I work a lot like Vero does during teaching, I am positive to this change. And Option 2 sounds fine. Between the lines I somehow read the idea to make the GUI a bit more RStudio / Spyder like. That sounds very interesting to me as it could actually simplify the GUI layout a bit. We have a Console in the GUI (with limited functionality) and a Python tab. I understand that this would be a bigger issue and involve significantly more work. Maybe a GSoC project for 2021? Cheers Stefan -Original Message- From: grass-dev On Behalf Of Luca Delucchi Sent: torsdag 10. september 2020 23:25 To: Vaclav Petras Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] Make terminal window optional? On Sun, 6 Sep 2020 at 05:06, Vaclav Petras wrote: > > Dear all, > Hi Vaclav, > > 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 is fine for me > Best, > Vaclav > -- ciao Luca www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Make terminal window optional?
On Sun, 6 Sep 2020 at 05:06, Vaclav Petras wrote: > > Dear all, > Hi Vaclav, > > 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 is fine for me > Best, > Vaclav > -- ciao Luca www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Make terminal window optional?
Hi Vashek, Thanks much for all the explanations :) I guess yes, option 2 is fine (not much will change for me indeed). I'll only reinforce the suggestion of the OSGeo4W installer for Windows users in the future. Vero El mié., 9 sept. 2020 a las 5:50, Vaclav Petras () escribió: > Hi Vero, > > I think the question is if a specific workflow is what we are aiming for > or if anything that gets users to a terminal+GUI combo is good as long as > there is not much work for the user. The issue is that some options are > just much more difficult to implement then the others. Or, in other words, > the question is what is a sufficient solution. > > On Mon, Sep 7, 2020 at 7:10 PM Veronica Andreo > wrote: > >> >> I am ok with not having the terminal when starting grass from an icon, >> but as Steven, I'd like to have a button to still be able to open the >> terminal from the GUI. For example, next to the icon for the simple Pyhton >> editor in the menu bar. >> > > Would you still want to have that button there even if that means that it > won't be as simple as "Open integrated Python editor" from a user point of > view because there will need to be some configuration involved? Or in other > words, even if there is a default, it won't work for some people. Is that > still worth it? (See also my email to Steven Pawley for additional details > on this.) > > Additionally, as I mentioned in the original post, it seems to me (and I > would be happy to be wrong on this) that we might not be able to close some > of the terminals. The issue is that we basically need access to the shell > started there which might be possible. This might be doable by developing a > mechanism to tell GUI about the shell's PID from the shell itself (now we > do something like that but are driving that from Python). In any case, it > would partially rely on the user configuring it properly (because of the > need for configuration). > > One possible way of this is saying we don't care about the prompt, > history, and invalid session in this terminal once the main process > finishes. > > >> In my case, I teach Grass from the terminal mostly and we use the gui to >> display results and such. The workflow would then change to open a >> terminal, call grass --text and then call the GUI with >> g.gui... I think that might get even more confusing to students... >> > > So what about the option 2 then? You open a terminal, type `grass`, hit > Enter, and by default you get the shell (because you are in an interactive > terminal - that can be detected) and the GUI starts, i.e., exactly what > happens now. > > Vaclav > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 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 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 > 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
Re: [GRASS-dev] Make terminal window optional?
Hi Vero, I think the question is if a specific workflow is what we are aiming for or if anything that gets users to a terminal+GUI combo is good as long as there is not much work for the user. The issue is that some options are just much more difficult to implement then the others. Or, in other words, the question is what is a sufficient solution. On Mon, Sep 7, 2020 at 7:10 PM Veronica Andreo wrote: > > I am ok with not having the terminal when starting grass from an icon, but > as Steven, I'd like to have a button to still be able to open the terminal > from the GUI. For example, next to the icon for the simple Pyhton editor in > the menu bar. > Would you still want to have that button there even if that means that it won't be as simple as "Open integrated Python editor" from a user point of view because there will need to be some configuration involved? Or in other words, even if there is a default, it won't work for some people. Is that still worth it? (See also my email to Steven Pawley for additional details on this.) Additionally, as I mentioned in the original post, it seems to me (and I would be happy to be wrong on this) that we might not be able to close some of the terminals. The issue is that we basically need access to the shell started there which might be possible. This might be doable by developing a mechanism to tell GUI about the shell's PID from the shell itself (now we do something like that but are driving that from Python). In any case, it would partially rely on the user configuring it properly (because of the need for configuration). One possible way of this is saying we don't care about the prompt, history, and invalid session in this terminal once the main process finishes. > In my case, I teach Grass from the terminal mostly and we use the gui to > display results and such. The workflow would then change to open a > terminal, call grass --text and then call the GUI with > g.gui... I think that might get even more confusing to students... > So what about the option 2 then? You open a terminal, type `grass`, hit Enter, and by default you get the shell (because you are in an interactive terminal - that can be detected) and the GUI starts, i.e., exactly what happens now. Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Make terminal window optional?
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 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
Re: [GRASS-dev] Make terminal window optional?
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 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
Re: [GRASS-dev] Make terminal window optional?
Hi all, I am ok with not having the terminal when starting grass from an icon, but as Steven, I'd like to have a button to still be able to open the terminal from the GUI. For example, next to the icon for the simple Pyhton editor in the menu bar. In my case, I teach Grass from the terminal mostly and we use the gui to display results and such. The workflow would then change to open a terminal, call grass --text and then call the GUI with g.gui... I think that might get even more confusing to students... my 2 cents Vero Vero El dom., 6 sept. 2020 a las 16:56, Steven Pawley () escribió: > Hi Vaclav, > > Thanks for this. My 2c is that the terminal should be made as optional > because it can definitely be confusing and intimidating/off-putting for new > users. Apologies if I’ve confused some of the options but here are my > thoughts regarding the start-up options. > > 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. > > 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. 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. 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. > > 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. > > Steve > > > On Sep 5, 2020, at 9:05 PM, Vaclav Petras wrote: > > 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.) > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Make terminal window optional?
Hi Vaclav, Thanks for this. My 2c is that the terminal should be made as optional because it can definitely be confusing and intimidating/off-putting for new users. Apologies if I’ve confused some of the options but here are my thoughts regarding the start-up options. 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. 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. 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. 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. 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. Steve > On Sep 5, 2020, at 9:05 PM, Vaclav Petras wrote: > > 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.) > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Make terminal window optional?
On 06-09-2020 05:05, Vaclav Petras wrote: 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 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? 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. 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 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. 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? 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 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
[GRASS-dev] Make terminal window optional?
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 terminal. 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. Best, Vaclav [1] https://trac.osgeo.org/grass/ticket/3474 [2] https://github.com/OSGeo/grass/pull/768 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
