-
-
Notifications
You must be signed in to change notification settings - Fork 926
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
Fullscreen auto-iconify causes problems for multi-monitor setups #1605
Comments
This issue seems to be very similar to #1602. If this behaviour is indeed caused by the GLFW_AUTO_ICONIFY setting and there are no negative side-effects to changing it, I'd also like to see it changed. |
Yes, this seems to be a duplicate of #1602 - don't know how I missed that ticket. :) Regarding GLFW_AUTO_ICONIFY = false, there are no negative side-effects that I've noticed on my Linux workstation (X.Org v1.20.4). The guy having problems with this option in #246 was running OS X. No idea if it's still a problem on Macs, but regardless, it would not be an argument against making GLFW_AUTO_ICONIFY configurable as long as the default is not changed. |
I could not reproduce issue #246 on my Mac. |
Interesting, I am in principle ok with this, but it requires some careful investigation on all platforms to ensure it has no side-effects. The most important side-effect I can think of is that it might make it impossible to change from one application to another on some platforms/window managers. |
My gut feeling is that the different behavior is caused by different ways of implementing fullscreen on different systems. Most applications want to allow other windows to be on top of a fullscreen application (to avoid the issue from #246), so the safest way to do fullscreen is to explicitly resize the window to the current monitor resolution, disable window manager decorations, and move the window to the top left corner. This is how GLFW does fullscreen on my system. I can actually make my window manager move the fullscreen window around, which proves it is just a plain-old undecorated window that happens to exactly fill the display area, not a hard fullscreen mode switch. In summary, a more portable fix than GLFW_AUTO_ICONIFY = false may be to change the fullscreen toggle function to do "soft" fullscreen. |
But is there a portable way to do soft fullscreen that would work across window managers? What about tiling WMs? Or WMs that dont allow applications to move their windows around for other reasons, or that dont respect the no-decoration hint? |
SDL has SDL_WINDOW_FULLSCREEN_DESKTOP which implements soft fullscreen in a - presumably - portable way. Have not looked at the implementation yet. |
That probably uses an EWMH hint, which is not really robust, in that |
Exactly. Even if it's not portable to all platforms/WMs, it would be nice if kitty provides the option to use soft fullscreen for WMs that support it. Fullscreen is not very useful for multi-monitor setups when auto-iconify is enabled. |
#246 is not relevant anymore since on macOS kitty uses the OS provided fullscreen mechanisms, it does not take over the screen. To fix this issue properly one would need to add support to glfw to use window manager based full screen on both X11 and wayland as well. |
My workstation has multiple monitors, and I like to keep a fullscreen terminal on one monitor while using the other monitors for reading documentation, etc. Unfortunately, kitty does not allow this since it auto-iconifies when losing focus to another window. This was easily fixed by setting GLFW_AUTO_ICONIFY to false in create_os_window(), so I'm wondering why this isn't the default, or why it isn't even configurable. I did see #246, but I am not having any of the negative side-effects mentioned in that bug report. I would be happy to provide a patch to make GLFW_AUTO_ICONIFY configurable, if it would be merged to master.
The text was updated successfully, but these errors were encountered: