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?

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 ;-)

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.

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.

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.

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.

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.

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?

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