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

[wenzeslaus]

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.

[hellik]

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]

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]

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]

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]

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]

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]

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]

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?

[nilason]

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.

[wenzeslaus]

Back to what prevented this from being merged: The following GIS Geography review strongly suggests that "the black thing" which starts with GRASS GIS is unexpected behavior on Windows.

GIS Geography: GRASS GIS – Geographic Resources Analysis Support System:

CONS
...
Command-line window running in the background

Expect the unexpected for user interface
...
You have a command line window running in the background the whole time the program is open

[echoix]

Does this still make sense now? It's a single line change, is someone with a Linux desktop test it again (4 years later)

[marisn]

Does this still make sense now? It's a single line change, is someone with a Linux desktop test it again (4 years later)

There is nothing to test. There simply is no consensus how it should work.

We should keep in mind that on Debian is possible to install GRASS without GUI and the desktop file still gets installed (=GRASS shows up in KDE app launcher). Thus Debian packagers would have to patch the desktop file anyway to avoid confusing "nothing happened when I clicked on GRASS icon".
Of course the best solution would be to have two desktop files – "GRASS" and "GRASS CLI" as it is done on Windows.

[wenzeslaus]

...on Debian is possible to install GRASS without GUI and the desktop file still gets installed (=GRASS shows up in KDE app launcher).

It seems strange to me that a desktop file would be installed for a CLI only application, although perhaps Octave behaved this way at least in the past. At this point, I get nothing for Python in the desktop app search on (Debian/Ubuntu based) Pop!_OS and for Octave, I get the desktop app. After starting a terminal window, I can run python and octave to get the respective interactive shell.

Installing a desktop file for the GUI package seems to me like the way to go, i.e., distributions should not install desktop file for the CLI package of GRASS GIS, only for the GUI one.

[echoix]

So, does this PR do this? Should it be closed?

[marisn]

It seems strange to me that a desktop file would be installed for a CLI only application, although perhaps Octave behaved this way at least in the past. At this point, I get nothing for Python in the desktop app search on (Debian/Ubuntu based) Pop!_OS and for Octave, I get the desktop app. After starting a terminal window, I can run python and octave to get the respective interactive shell.

Installing a desktop file for the GUI package seems to me like the way to go, i.e., distributions should not install desktop file for the CLI package of GRASS GIS, only for the GUI one.

@sebastic any comments on this?

[sebastic]

The Debian package just ships the grass.desktop installed by the grass build.

It's up to the GRASS developers whether they want to provide separate desktop integrations for the GUI and CLI, switch the existing desktop file from CLI to GUI, or leave things as they are. If the desktop file is changed to launch the GUI, the file will simply move from the grass-core to the grass-gui package.

[marisn]

It's up to the GRASS developers whether they want to provide separate desktop integrations for the GUI and CLI, switch the existing desktop file from CLI to GUI, or leave things as they are. If the desktop file is changed to launch the GUI, the file will simply move from the grass-core to the grass-gui package.

Thank you for explanation.

I would vote for discarding this PR and creating two desktop files instead – one with grass --text as "GRASS CLI" with Terminal=true and "GRASS GUI" with Terminal=false. Then on Debian one would come with -core and the second with -gui packages.
@veroandreo ?

[echoix]

Why not just do it in here? It seems small and relates to the discussion that happened here.