SDL_HINT_VIDEO_MAC_FULLSCREEN_SPACES = 0 does not disable maximize button on window bar

[SRSaunders]

I call SDL_SetHint( SDL_HINT_VIDEO_MAC_FULLSCREEN_SPACES, "0" ) before SDL_Init( SDL_INIT_VIDEO ), and then I create a Vulkan window using SDL_CreateWindow() with flags = SDL_WINDOW_VULKAN | SDL_WINDOW_RESIZABLE.

It appears that fullscreen spaces are indeed disabled, however the green maximize button is still present on the window title bar. According to the documentation, the maximize button should be disabled for SDL_WINDOW_RESIZABLE windows when the hint is active.

If you press the maximize button, the macOS window manager will override the hint and use spaces which I do not want for my game. I require true SDL_WINDOW_FULLSCREEN_DESKTOP behaviour which I have implemented via program control, but don't want a user to override this by using the maximize button.

Running macOS Monterey 12.6. with SDL2 version 2.26.4

[slime73]

Even without the maximize button (which can be turned off by avoiding SDL_WINDOW_RESIZABLE, and also has dual functionality on macOS where users can hold alt while pressing it to have a maximized window in the same Space), can't users place your window into its own Space regardless, by using the system Mission Control functionality or whatever it's called?

In other words, I think macOS gives more control to users rather than app developers about the user's use of Spaces.

[SRSaunders]

Your comments above are generally true about macOS spaces, but SDL offers functionality to override that under program control. I am simply reporting what I think is a bug versus what is written in the documentation. See https://wiki.libsdl.org/SDL2/SDL_HINT_VIDEO_MAC_FULLSCREEN_SPACES

According to this doc, when the hint is 0, the following should be true:

"0" : disable Spaces support (FULLSCREEN_DESKTOP won't use them and SDL_WINDOW_RESIZABLE windows won't offer the "fullscreen" button on their titlebars)

I have verified that when I fullscreen the window using SDL_WINDOW_FULLSCREEN_DESKTOP, the hint appears to be working and spaces are not used. However, the other part of the doc regarding the fullscreen (maximize) button is not being respected - i.e. the button is still present and active. And I do require SDL_WINDOW_RESIZABLE windows so I can't turn that flag off.

I wonder if this is due to using Vulkan vs. OpenGL, or if the defect is general in nature.

[LilBoom69]

It's possible that there is a bug in SDL's implementation of this hint on macOS, as the documentation does indeed state that the maximize button should be disabled when the hint is active for resizable windows.

You can try reporting the issue to the SDL development team on their bug tracker or forum to see if they can provide a fix or a workaround for your specific use case.

In the meantime, you could try manually disabling the maximize button using the macOS API, although this may not be a trivial task. Alternatively, you could try creating a custom window frame that doesn't include the maximize button at all, although this would require more work to implement.

[slime73]

You can try reporting the issue to the SDL development team on their bug tracker

This is the SDL bug tracker...

I took a quick look at the code and I wonder if macOS changed a default value for window properties at some point, which would cause a problem like this if so (given what SDL's code does), but I haven't run any real tests yet.

I suppose if they did that it would probably have been around the time they switched the go-into-a-fullscreen-space button from a standalone button (which it used to be in 10.7) into something that's merged with the maximize button.

[SRSaunders]

Interesting conjecture. I wonder if it would be possible for the SDL hint to force the button into single-function legacy functionality (i.e. maximize mode vs dual go-into-a-fullscreen-space/maximize mode). As you mentioned earlier, an option-click activates the legacy maximize functionality (now called Zoom in the UI). Having this work by default without the option key when the SDL hint is active would be ideal.

[SRSaunders]

@slime73 - Do you have any update or plans to address this deficiency versus the documented spec?