-
-
Notifications
You must be signed in to change notification settings - Fork 802
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
Do not synthesize window size for MAXIMIZED/FULLSCREEN/TILED states #6182
base: main
Are you sure you want to change the base?
Conversation
Could you please test this change, then? I wasn't able to reproduce any weird behaviour with Gnome, myself. Also note that the toggle_fullscreen code that was introduced by the same change is still in place, and it's possible other changes to wezterm (or gnome) since have fixed the other issues too. |
Yes, the issue still exists when apply this patch. Initial issue with configuration event. Some logs to explain issue on Gnome:
Similar behavior for FULL_SCREEN and TILED actions. |
Created issue for tracking: #6262 |
It is the responsibility of the Wayland compositor to set the correct size for the window when it is tiled or maximized.
https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state also states that in the maximized case, the client needs to obey the geometry provided by the compositor.
Also, in the fullscreen case, with this code in place, Wezterm ends up not taking up the entire screen when there's some kind of bar/panel (easy to reproduce with the default Gnome desktop).
Since the code was added in response to #6108 I have tested this change against Gnome (47.0.1). The other compositors I've tested against are Niri and Sway; With both Niri and Sway, TILED_TOP/BOTTOM/LEFT/RIGHT are set. Sway isn't broken by this code because it doesn't provide suggested_bounds. With Niri,
pending_event.configure.replace((w / 2, h));
always runs, and it is completely impossible to resize the window (other than making it fullscreen).