-
Notifications
You must be signed in to change notification settings - Fork 29.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add window.nonNativeFullscreen option for macOS #55267
Conversation
1a3fed8
to
2edf933
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ignu this is a great change, thanks for doing it. Looking at the screenshot from iTunes, I wonder if we should flip the setting around to be enabled by default and called window.nativeFullscreen
I would even literally copy the description they have there below the setting to VSCode to explain when it would make sense to disable that setting.
@ignu one thing I noticed is that Sublime Text no longer seems to advertise this setting because when you enter simple full screen, it is hard to get out of this mode unless you know how you entered it. We could maybe show a message informing the user how to get out of the full screen mode if the native full screen mode is disabled? |
@bpasero That's a good point. I was thinking the default being a double-negative could be confusing. But as much as I dislike Apple's native fullscreen, I'd worry about making "non-native" or "simple" the default. I'm not aware of any macOS app that does that, and it'd change Code's behavior and change it in a way that's not a macOS standard. I'm sure at least a few people would be upset. Leaving the default native also prevents the confusion of accidentally getting into So I'd propose I get rid of the double negative and updating the description text as your proposed. Maybe make the option and default one of:
|
@bpasero updated. I didn't completely grab that description as it is since it's a bit out of date. (When native full screen first launched, secondary monitors were completely useless.. they were just blanked out. That's no longer the case, but they're still not ideal since you can't drag windows from them to your natively full-screened app's window.) I also prevented the maximize button from going into native fullscreen if |
@ignu changes look good to me, however I am seeing two bugs, that seem to be related to the fullscreen support:
|
That's really weird. I think CMD+Q's not working because it's like the entire application doesn't have focus? I'm poking around now. |
@ignu well it does not even work after I click back into the application. Maybe something is seriously broken in this mode in Electron already when you once set simple fullscreen. |
@bpasero I didn't find it in the electron docs, but I found this snippet in an electron nvim gui I added that to 476a89d and fixed most of the problems There is a remaining bug... if you try to quit from simpleFullScreen, you're can't quit anymore, not through CMD+Q or even I think something must be puking trying to serialize, but I'm not totally sure. Still digging in. |
@ignu yeah I also thought about adding focus, but I did not try with It could be that our very own logic prevents the quit, running with |
476a89d
to
a64ea32
Compare
a64ea32
to
41cd80e
Compare
Yeah. I'm not fully groking everything Continued attempts to quit (even when backing out of full-screen) result in
but continued |
@ignu turns out this is a known Electron bug, we will have to wait for a fix from them: electron/electron#13135 |
@ignu I have updated master to I pushed a couple of cleanup changes to your branch and was about to merge, but then I figured out two things:
It could be that I did not see this issue before because I never tested running out of sources with the standard custom title behaviour (that needs the 2 changes I mention above). Can you check? |
I'll look at that title issue tonight. I just realized it's not consistent with native fullscreen. I've actually been using my own build of Code with these commits in it for the last month. I like the title there since my workflow (and part of why i hate native fullscreen) is having many projects open, and the title helps me identify which window I've Option-Tabbed to quickly... but it probably should be consistent with the native fullscreen version. The other bug I have to fix that I've recently noticed is that if my resolution changes due to switching monitors Code is in |
@ignu ok thanks. any thoughts on the exception in the |
167a68c
to
2b86094
Compare
Thanks again 👍 |
Now that Electron 2 is merged into master, we can have simpleFullScreen support!
Adds a new configuration option
window.nonNativeFullScreen
(defaulted tofalse
to preserve the existing behavior) that, when true, will usesetSimpleFullScreen
and not cause the creation of a new space.Fixes #5344