Skip to content
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

Closed
hakonrk opened this issue May 9, 2019 · 10 comments
Closed

Fullscreen auto-iconify causes problems for multi-monitor setups #1605

hakonrk opened this issue May 9, 2019 · 10 comments

Comments

@hakonrk
Copy link

hakonrk commented May 9, 2019

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.

@Luflosi
Copy link
Contributor

Luflosi commented May 9, 2019

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.

@hakonrk
Copy link
Author

hakonrk commented May 9, 2019

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.

@Luflosi
Copy link
Contributor

Luflosi commented May 9, 2019

I could not reproduce issue #246 on my Mac.

@kovidgoyal
Copy link
Owner

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.

@hakonrk
Copy link
Author

hakonrk commented May 10, 2019

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.

@hakonrk hakonrk closed this as completed May 10, 2019
@hakonrk hakonrk reopened this May 10, 2019
@kovidgoyal
Copy link
Owner

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?

@hakonrk
Copy link
Author

hakonrk commented May 10, 2019

SDL has SDL_WINDOW_FULLSCREEN_DESKTOP which implements soft fullscreen in a - presumably - portable way. Have not looked at the implementation yet.

@kovidgoyal
Copy link
Owner

That probably uses an EWMH hint, which is not really robust, in that
window managers are free to ignore it/not implement it. Still maybe
worth using that as the default fullscreen implementation rather
than taking over the screen as glfw does, which is probably more suited
to games than desktop apps.

@hakonrk
Copy link
Author

hakonrk commented May 10, 2019

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.

@kovidgoyal
Copy link
Owner

#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants