Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

init: Do not ask for a terminal in the freedesktop entry #1221

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

@wenzeslaus
Copy link
Member

@wenzeslaus wenzeslaus commented Dec 31, 2020

This PR specifies that the GRASS GIS desktop application should not start with a terminal in the Freedesktop Desktop Entry (.desktop file).

Based on the discussion in Make terminal window optional? (grass-dev, Sep 5-12, 2020) we are going with (option 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.

In other words, the terminal experience with an interactive shell is now opt-in with this PR.

The correct behavior (i.e., not a failure) without an interactive terminal is enabled by 171db2e (#768). The GUI will provide a clear application main window title after #1216 and a smooth quit experience after #1219.

This PR only changes the .desktop file provided with GRASS GIS. It does not change any actual installers or packages, especially no change is done for Windows and macOS.

Package/installer maintainers, please take an action for your platform. Open separate PRs if applicable.

This specifies that the GRASS GIS desktop application should not start with
a terminal in the Freedesktop Desktop Entry file.
@hellik
Copy link
Member

@hellik hellik commented Dec 31, 2020

so, the intention is to start the GUI without a console (e.g. windows console in winGRASS)?

How should a user proceed if he needs a console for data processing e.g. with GDAL? starting an extra console?

@hellik
Copy link
Member

@hellik hellik commented Dec 31, 2020

When a user starts GRASS GIS using a command from an existing terminal, there is no change from the current behavior

that's a very linux centered view of world.

the windows part of the world doesn't work in that waya

as there is no terminal to launch programs as in linux.... dll hell is greeting you ;-)

@nilason
Copy link
Contributor

@nilason nilason commented Jan 4, 2021

I've been experimenting with starting without terminal using grass-conda package repo with success (I have not yet pushed any changes there, but the concept is feasible).

How should a user proceed if he needs a console for data processing e.g. with GDAL? starting an extra console?

This is a crucial question for this kind of distribution (GRASS.app) for Mac. A possible and workable solution would be adding a setting to ~/.grass7/wx.json: something like general:init:startWithoutShellIfPossible:enabled, which is then read at startup.

@wenzeslaus
Copy link
Member Author

@wenzeslaus wenzeslaus commented Jan 5, 2021

A possible and workable solution would be adding a setting to ~/.grass7/wx.json: something like general:init:startWithoutShellIfPossible:enabled, which is then read at startup.

I don't know what in (the current) GRASS GIS (code) should be driven by this settings. GRASS GIS does not decide about the terminal in which it runs (e.g. Gnome Terminal). It only decides about starting or not starting a shell (e.g. Bash). The presence of terminal is detemined by the system (i.e., installation) or the user (by system configuration or on-the-fly). This is exactly why 171db2e (#768) is need. GRASS GIS can be started without a terminal and in that case, no shell can be started, so 171db2e starts with shell "only if possible," i.e., only when there is a terminal. On the other hand, the point of this PR is to install/configure GRASS GIS in the system in such as way that clicking a "start GRASS GIS" menu item or icon does not open a terminal window, but only the GUI. Importantly, it does not influence how GRASS GIS behaves when started from a interactive terminal.

@wenzeslaus
Copy link
Member Author

@wenzeslaus wenzeslaus commented Jan 5, 2021

so, the intention is to start the GUI without a console (e.g. windows console in winGRASS)?

Right, that black thing on Windows should go away.

How should a user proceed if he needs a console for data processing e.g. with GDAL? starting an extra console?

What do you think is appropriate for a typical Windows user? For example, the Console in GUI provides access to the command line tools.

@wenzeslaus
Copy link
Member Author

@wenzeslaus wenzeslaus commented Jan 5, 2021

When a user starts GRASS GIS using a command from an existing terminal, there is no change from the current behavior

that's a very linux centered view of world.

the windows part of the world doesn't work in that way

How this should behave on Windows is whatever matches the basic idea behind this PR: If GRASS GIS is started in the standard way, only the GUI opens, not the terminal. Advanced users who wish to use an actual command line shell and not just Console in GUI should be able to do whatever is common on their platform, e.g., starting a terminal application and executing GRASS GIS (as a command or path to an executable) and getting a (sub-)shell in GRASS GIS session.

@nilason
Copy link
Contributor

@nilason nilason commented Jan 5, 2021

A possible and workable solution would be adding a setting to ~/.grass7/wx.json: something like general:init:startWithoutShellIfPossible:enabled, which is then read at startup.

I don't know what in (the current) GRASS GIS (code) should be driven by this settings.

For a GRASS.app that code would be in:
https://github.com/OSGeo/grass/blob/master/macosx/app/GRASS.applescript
(which at present doesn't work)

For a working example, see draft at:
https://github.com/nilason/grass-conda/blob/test-without-terminal/files/Grass-7.9.dev

GRASS GIS does not decide about the terminal in which it runs (e.g. Gnome Terminal). It only decides about starting or not starting a shell (e.g. Bash). The presence of terminal is detemined by the system (i.e., installation) or the user (by system configuration or on-the-fly). This is exactly why 171db2e (#768) is need. GRASS GIS can be started without a terminal and in that case, no shell can be started, so 171db2e starts with shell "only if possible," i.e., only when there is a terminal. On the other hand, the point of this PR is to install/configure GRASS GIS in the system in such as way that clicking a "start GRASS GIS" menu item or icon does not open a terminal window, but only the GUI. Importantly, it does not influence how GRASS GIS behaves when started from a interactive terminal.

Forgive me for perhaps explaining obvious things. An app-bundle for macOS (e.g. GRASS.app) is in fact a directory typically represented in GUI with an icon (the ".app" part of the name it is hidden). It is double-clickable to start the app. This app-bundle contains everything needed, in the case of the miniconda based build of https://github.com/nilason/grass-conda/, all dependencies and GRASS code is located within (amounting to at present a massive 1.8 GB!):

GRASS-7.8.app
+-- Contents
    +-- Info.plist
    +-- MacOS
        +-- GRASS (this is the start-up executable file, as stated in Info.plist)
        [...]
    +-- Resources
        +-- AppIcon.icns
        +-- AUTHORS
        +-- bin
        +-- CHANGES
        +-- CITING
        +-- contributors_extra.csv
        +-- contributors.csv
        +-- COPYING
        +-- demolocation
        +-- doc
        +-- docs
        +-- driver
        +-- etc
        +-- fonts
        +-- GPL.TXT
        +-- GRASSDocument_gxw.icns
        +-- gui
        [...]

For the typical Mac user, app-bundles are the expected way to start applications and to be distributed. They are, by design, completely self contained and are not included in e.g. shell env PATH and others by default (and shouldn't be!). It is not an option to "just" fire up a terminal window and do a /Applications/GRASS-7.8.app/Resources/bin/python3 /Applications/GRASS-7.8.app/Contents/Resources/bin/grass78 --gui to have the terminal shell. That wouldn't work off-the-shelf and is not expected behaviour by Mac users. The terminal shell environment should be set by the start-up executable file and it should be able to set the preference (with or without terminal shell) in GUI.
If no other platforms can make use of a setting like general:init:startWithoutShellIfPossible:enabled it can perhaps be conditioned into GUI Settings for Mac only, I can understand it may only be disturbing on a platform where it doesn't make sense.

@wenzeslaus
Copy link
Member Author

@wenzeslaus wenzeslaus commented Jan 9, 2021

For a GRASS.app that code would be in:
https://github.com/OSGeo/grass/blob/master/macosx/app/GRASS.applescript
(which at present doesn't work)

For a working example, see draft at:
https://github.com/nilason/grass-conda/blob/test-without-terminal/files/Grass-7.9.dev

... The terminal shell environment should be set by the start-up executable file and it should be able to set the preference (with or without terminal shell) in GUI.

That makes sense to me and it seems to me as a corresponding solution for this PR for macOS.

If no other platforms can make use of a setting like general:init:startWithoutShellIfPossible:enabled it can perhaps be conditioned into GUI Settings for Mac only, I can understand it may only be disturbing on a platform where it doesn't make sense.

For Linux this would be an interesting feature, but it is not needed. The workflow and path expectations are different and if you really desire terminal after clicking the "icon," it is quite easy to change it. It would be also difficult to implement.

I'm not sure what you mean by startWithoutShellIfPossible. What do you mean by shell and when staring without is is not possible? That's perhaps discussion for #1227.

@hellik is startWithoutShellIfPossible-based solution something which would fit well on Windows or do you think something else is more appropriate?

Copy link
Contributor

@nilason nilason left a comment

I'm not sure what you mean by startWithoutShellIfPossible. What do you mean by shell and when staring without is is not possible? That's perhaps discussion for #1227.

With "shell" I mean a Terminal shell. An installation with e.g. MacPorts, will give/gives the opportunity to start by "clicking the icon" as well as through terminal (as grass7x binary is in the PATH in that case). In the latter case it doesn't make any sense to not start with terminal shell. But let's continue this discussion in #1227.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants