cocoa: Add a hint to control menu visibility in fullscreen spaces windows

[Kontrabant]

Adds SDL_HINT_VIDEO_MAC_FULLSCREEN_MENU_VISIBILITY to control whether or not the menu can be accessed when the cursor is moved to the top of the screen when a window is in fullscreen spaces mode.

The three values are 'always', 'never', and 'auto' (default), with auto resulting in a hidden menu if fullscreen was toggled programmatically, and the menu being accessible if fullscreen was toggled via the button on the window title bar, so the user won't be stuck in fullscreen if the client app/game doesn't have a readily available option to toggle it.

Will leave this open for a bit to see if anyone has an opinion on a different default setting, or if this should just be a boolean always/never.

Fixes #8518

[slouken]

Suggested change

	* - "always": The menu will always be accessible when the window is in a fullscreen space.
	* - "1": The menu will be accessible when the window is in a fullscreen space.

[slouken]

Suggested change

	* - "never": The menu will always be hidden when the window is in a fullscreen space.
	* - "0": The menu will be hidden when the window is in a fullscreen space and not accessible by moving the mouse to the top of the screen.

[icculus]

The backend code looks good at first glance, but do we want a hint, or to just always work like the "auto" option?

I'm thinking that a user that maximizes to a fullscreen space and then can't get back at the menu because the app set this to "never" is sort of user-hostile, and if the app explicitly put it in a fullscreen space programatically, they probably don't ever want the menu there (in which case the user can still command-tab out, or switch Spaces, etc, even if the app didn't provide UI to exit fullscreen mode).

tl;dr: it should probably always have the menu if the app is a resizable window that happens to be clicked-through to fullscreen, and never otherwise, right?

CC @slime73 for her opinion on the topic.

[slime73]

I'm thinking that a user that maximizes to a fullscreen space and then can't get back at the menu because the app set this to "never" is sort of user-hostile

Personally I agree, and I think this was one of the reasons clicking that button in SDL2 made the SDL window state "maximized" instead of fullscreen - or at least one of the reasons it stayed that way throughout SDL2's lifetime.

It's too bad SDL can't really guarantee that an app must have a way to correctly exit fullscreen in the app's UI if the system UI is hidden, maybe just a warning in the hint's description would be good enough?

if the app explicitly put it in a fullscreen space programatically, they probably don't ever want the menu there (in which case the user can still command-tab out, or switch Spaces, etc, even if the app didn't provide UI to exit fullscreen mode).

It's possible some apps (maybe non-game ones in particular?) might want the system UI after programmatically entering fullscreen, but I'm just imagining a use case rather than having one myself. I don't have a strong opinion either way about that part I think.

This is a little similar to SDL_HINT_IOS_HIDE_HOME_INDICATOR on iOS, but the app model is different enough there that I think the macOS behaviour deserves its own set of rules.

[Kontrabant]

It's too bad SDL can't really guarantee that an app must have a way to correctly exit fullscreen in the app's UI if the system UI is hidden, maybe just a warning in the hint's description would be good enough?

There is the 'fn + f' key shortcut, although that requires users to know that it exists, and have a keyboard with the fn key.