Winit: Expected behavior of fullscreen and maximized in MacOS

[edwin0cheng]

After PR https://github.com/tomaka/winit/pull/457 is merged, I am going to implement following missing / incorrect (https://github.com/tomaka/winit/issues/66, https://github.com/tomaka/winit/issues/300) of display features in macos:

• Window::set_fullscreen and WindowBuilder::with_fullscreen
• Window::set_maximized and WindowBuilder::with_maximized
• Window::set_decoration

However, i didn't know what is the expected behavior of "Full Screen" in macos :

• Should full screen show / hide / auto-hide the menu bar ?
• Should maximized show / hide / auto-hide the dock ?
• If i implemented this changes, will it break others projects (e.g. alacritty @jwilm) ?

[mitchmindtree]

These are just my personal expectations, based on being a mac user for a long time (before recently switching to linux). The following also corresponds with how X11 behaves for the most part.

Should full screen show / hide / auto-hide the menu bar ?

Yes, the "inner area" of the window should take up the whole screen and no menubar or decorations should be visible. The menu bar behaviour that I would expect would be "auto-hide", where it only appears if you move your mouse cursor to the top of the screen.

One thing worth considering here is whether or not the fullscreen should occur in a new "desktop" as seems to be the behaviour of most macos apps. I'm not really sure what the right answer is here.

Should maximized show / hide / auto-hide the dock ?

I don't think hiding the dock is necessary - I would expect this to simply set the outer dimensions of the window to the size of the screen.

[edwin0cheng]

I don't think hiding the dock is necessary - I would expect this to simply set the outer dimensions of the window to the size of the screen.

When i clicked on "green icon" (e.g safari) , it will take up the whole screen but set the menubar and dock to auto-hide.
When i clicked on "green icon" with Option, it will not hide the dock, and just make the outer dimensions to the size of the screen which show the dock and menu bar.

So should we map set_maximized to ?:

• green icon
• green icon with Option

[mitchmindtree]

Yes I think following safari's conventions is a good idea. That is, mapping set_maximized to "green icon with Option" and set_fullscreen to "green icon".

I cannot comment much further on auto-hiding the dock as I did not use the dock.

[sodiumjoe]

Just to throw my two cents in here, I agree with following Safari's convention, which I believe is just macos convention. I imagine anyone who wants faux full-screen behavior that leaves the menu bar and dock intact would already be using a window manager that can achieve this (I use hammerspoon for this).

[edwin0cheng]

Indeed, i just implemented these features following standard macos convention, which is just calling NSWindow::toggleFullscreen: for fullscreen and NSWindow::zoom for maximized.

However, set_decoration and with_fullscreen are little bit tricky:

• Calling toggleFullscreen: and zoom: on a non-resizable window (i.e set_decoration(false)) in MacOS is no-op by default, i have to do it manually (use setFrame for zoom) or set it to resizable tempority and restore it back. (for toggleFullScreen
• Normally, the implementation of with_fullscreen is just calling toggleFullscreen after window initialization. However, when a winit app is launched from a fullscreen app (e.g. from a FullScreen VS Code Terminal), it creates a new virtual desktop and a transition animation, which takes one sec and cannot be disabled. In this animation time, all toggleFullscreen events will be failed. The PR just makes another toggleFullscreen call with delay until it succeeds.

[swiftcoder]

Have we considered supporting two distinct fullscreen modes? One being the Safari-like mode that Mac desktop apps use at the current desktop resolution, with hidden menu bar and dock, and the other being a true fullscreen with captured display (custom resolution and no menu bar or dock at all) as games tend to use.

On Windows these equate to fullscreen borderless window, versus regular fullscreen (i.e. the choice of fullscreen modes that Blizzard presents in their games).

[edwin0cheng]

As i knew, in PR #270 , custom resolution are removed in X11 implementation, so i made the same change to #457. And in the MacOS side, i didn't implement resolution either.

The problem of custom resolution is, not all resolutions are supported by hardware, and there is still no api to query the supported resolution list right now. On the other hand, as stated in #270:

GPU scaling is cheap enough that apps should just scale to whatever the physical resolution is and not do any mode switching

For instance, let say we are using OpenGL as backend, it is not hard to create an framebuffer with custom resolution and then copy to screen frame buffer.

[vbo]

What I would like is a fullscreen on a new "desktop" with dock and menubar hidden, maybe even cmd+tab disabled so application can handle it in a custom way. I made a pull request to the underlying cocoa library to support necessary APIs. Would be nice if we could expose this through winit.

[edwin0cheng]

@vbo yes, that PR is what we needed, right now i didn't touch the Fullscreen options, so the default will be used.
And we could expose this in WindowExt and WindowBuilderExt, but i think i would recommend to create another PR to address it.

[vbo]

Sounds good, thanks @edwin0cheng. Let's revisit when PR is merged-in and see if I can add support in Window(Builder)Ext.

[edwin0cheng]

@vbo When i am trying to using NSView:: enterFullScreenMode:withOptions: , i found that NSViewFullScreenModeOptionKey is missing too, which i do not have any other options to bypass it, would you mind to bind it in your cocoa library PR too ?

[vbo]

Sure, I'll take a look. That PR already merged-in though, so this is going to be separate.

[vbo]

@edwin0cheng, just to clarify: you don't really need NSViewFullScreenModeOptionKey itself - this is just an alias for NSString *. Instead you want access to these constants, right?

[edwin0cheng]

Yes, thanks

[edwin0cheng]

As the PR https://github.com/tomaka/winit/pull/465 was merged, i would like to move the discussion to how to improve it. So i will close this issue and open https://github.com/tomaka/winit/issues/473 for improvements.