SUMMARY Resizable windows under Wayland aren't automatically shrunk to avoid having parts cut off like they are under X11. This affects a multitude of applications and toolkits, and after contacting both app devs and toolkits about this, see e.g. https://github.com/libsdl-org/SDL/issues/11747 , it seems to be the case that 1. this works with XWayland windows in a Plasma Wayland session but not Wayland windows, and 2. due to not knowing how large server side decorations will be this is apparently not easily solvable on the app or toolkit side. Therefore, this appears to be something KWin should probably be doing. Dealing with a too large window as a user requires multiple clicks. Since the lower border exceeding the screen bounds means it can't be directly grabbed, the window needs to be first shrunk from the top, then moved up via the title bar, then perhaps shrunk from the top again if the amount the user shrunk it was too few, then moved up again, and then finally the lower part will be reachable again. Doing this regularly for apps that spawn too large is time consuming and mechanically challenging. STEPS TO REPRODUCE 1. Have a small enough screen size and high enough DPI scaler that some resizable apps that choose a normally reasonable default size to launch at, will now have parts of the window cut off. It needs to be KDE Plasma 6 Wayland session, the app needs to be a native Wayland app, and the app needs to be resizable. 2. The app may now spawn too large to fit the screen. 3. The app can be manually resized to fit the screen now, but this is rather tedious. If you force the app to use an X11 socket and XWaland mode, it will be made to fit the screen without user intervention. OBSERVED RESULT Resizable windows that spawn from native wayland apps that can be easily manually resized to fit the screen, will spawn cut off. XWayland windows are resized to fit. EXPECTED RESULT Both native Wayland apps with resizable windows, as well as XWayland resizable windows, are resized to fit as long as the minimum window size geometry allows for that to happen. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: postmarketOS v24.12 based on 3.21.0 with kernel 6.12.4 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 ADDITIONAL INFORMATION
There is some new downstream discussion on the SDL bugtracker https://github.com/libsdl-org/SDL/issues/11747 whether this is a toolkit issue after all. In any case, it seems like SDL2 and GTK+ are both affected, so it might be a wider ranging problem no matter where the responsibility lies. My apologies if this isn't a kwin issue after all, I'm not sure where the actual culprit is.
It is an app/toolkit bug, but I think we should enforce windows to fit on the screen regardless. The first frame will still be wrong, so apps must be fixed either way though.
(In reply to Zamundaaa from comment #2) > It is an app/toolkit bug, but I think we should enforce windows to fit on > the screen regardless. The first frame will still be wrong, so apps must be > fixed either way though. I strongly disagree on this one. It's easier said than done properly. I looked into it in the past, it broke other things.
Given that the support for xdg_toplevel.configure_bounds landed, I suggest to close this bug report.
Isn't it still a problem in GTK+? (My apologies if I'm mixing things up.)
I tested this with GTK+ now and filed a bug, it does seem to be an ongoing problem: https://gitlab.gnome.org/GNOME/gtk/-/issues/7253 I haven't tested Qt yet.
Qt already supports it
Thanks so much for checking! Perhaps I should close this issue then, or should I wait until this was looked at by GTK+ to see what their take is?
GTK should already support xdg_toplevel.configure_bounds. Perhaps it's a regression
Oh, but I believe it's GTK4 only
Hmm, nope, gtk-3-24 also has it
[4230594.995] {Default Queue} xdg_toplevel#33.configure_bounds(2557, 1411) [4230595.001] {Default Queue} xdg_toplevel#33.configure(0, 0, array[0]) [4230595.007] {Default Queue} xdg_surface#32.configure(27897) [4230595.021] {Default Queue} -> xdg_surface#32.ack_configure(27897) [4230606.704] {Default Queue} -> wl_shm#7.create_pool(new id wl_shm_pool#35, fd 15, 6000000) [4230606.752] {Default Queue} -> wl_shm_pool#35.create_buffer(new id wl_buffer#36, 0, 500, 3000, 2000, 0) [4230611.604] {Default Queue} -> wl_surface#31.attach(wl_buffer#36, 0, 0) [4230611.623] {Default Queue} -> wl_surface#31.set_buffer_scale(1) [4230611.630] {Default Queue} -> wl_surface#31.damage(0, 0, 500, 3000) [4230611.637] {Default Queue} -> xdg_toplevel#33.set_min_size(0, 0) [4230611.645] {Default Queue} -> xdg_toplevel#33.set_max_size(0, 0) [4230611.665] {Default Queue} -> xdg_surface#32.set_window_geometry(0, 0, 500, 3000) [4230611.675] {Default Queue} -> wl_compositor#4.create_region(new id wl_region#37) [4230611.682] {Default Queue} -> wl_region#37.add(0, 0, 500, 3000) [4230611.688] {Default Queue} -> wl_surface#31.set_opaque_region(wl_region#37) [4230611.694] {Default Queue} -> wl_region#37.destroy() [4230611.700] {Default Queue} -> wl_surface#31.set_input_region(nil) [4230611.711] {Default Queue} -> wl_surface#31.frame(new id wl_callback#38) [4230611.718] {Default Queue} -> wl_surface#31.commit() yeah it seems like a gtk issue
Created attachment 177195 [details] Screenshot showing the problem occurring with GTK+ (not sure if version 3 or 4)
As a small update, GTK+ seems to think the apps should do this, but in practice I've seen plenty more popular ones that don't. That seems a bit unsatisfactory as an end user. https://gitlab.gnome.org/GNOME/gtk/-/issues/7253#note_2313906 Perhaps it could be some sort of KWin option?