Re: Make terminal window optional?
Veronica Andreo <[email protected]>
| Newsgroups | gmane.comp.gis.grass.devel |
|---|---|
| Message-ID | <CAAMki4GKX4UbCY2vX-TnX90JD9ZwQ9kD40=esiK=A6E3gy5MQw@mail.gmail.com> |
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 (<[email protected]>) 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 <[email protected]> > 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 [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev