| Summary: | On Wayland, struts are incorrect for vertical panels, causing Maliit and new horizontal panels to be mis-positioned | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Nate Graham <nate> |
| Component: | virtual-keyboard | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | benjamin.hennion, bugs.kde.org, cedjo7, dmatteo002, jps.sousa, kde, kdedev, niccolo.venerandi, niccolo, rob.dyck |
| Priority: | NOR | Keywords: | wayland |
| Version: | 5.27.8 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=459000 | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/e4f9df54e6f6f7db493ac8e20fbcdac393bbd270 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | Cover half the panel | ||
Fixed by Arjen Hiemstra with https://invent.kde.org/plasma/kwin/-/commit/7e25e20097fe8d140f7408b76fbf374fe5f33690 in Plasma 5.24.3 Apparently right edge panels are still affected; see Bug 459000. It's now broken again in Plasma 6 exactly as it was before this fix went in; re-opening. Hi Nate! For me it is broken on on Plasma 5. I'm using a vertical floating panel at the left of the screen and the maliit virtual keyboard doesn't overlap the panel but it gets its rightmost edge of the window off the screen partially blocking the keyboard keys as reported on https://bugs.kde.org/show_bug.cgi?id=474910. I guess it's related to the same issue origianlly reported. OS: NixOS 23.11 (unstable) KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 This appears to affect new panels too; creating a new horizontal panel when there's already a vertical panel causes it to be mis-positioned in exactly the same way as Maliit is. Seems like the vertical panel struts are wrong. I'm using the system at 200% scale, so I thought maybe the struts were in physical pixels and not logical pixels. However I tested at 100% scale, and the issue remained. *** Bug 459000 has been marked as a duplicate of this bug. *** *** Bug 474910 has been marked as a duplicate of this bug. *** *** Bug 477824 has been marked as a duplicate of this bug. *** Anyway, clear steps to reproduce: 1. Have a vertical panel on the left screen edge 2. Add a new blank horizontal panel or show the Maliit virtual keyboard somehow Both the new panel and also the Maliit virtual keyboard are positioned too far to the right. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3714 Git commit 6feb67b9fd1148634c022a87062c20a7955c1ac9 by David Redondo. Committed on 22/12/2023 at 08:55. Pushed by davidre into branch 'master'. Let the compositor size space filling panels There were two issues preventing to let the compositor size such panels: - the window needs to be anchored on opposite edges, so LayerShellQt requests size 0 (meaning the compositor should deciude) in that dimension - QtWayland currently will not size windows smaller than the requested minimum size. We can work around this by having a minimum size that's actually smaller than the screen dimension. This fixes a horizontal and a vertical panel next to each other to no longer overlap. M +9 -1 shell/panelview.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/6feb67b9fd1148634c022a87062c20a7955c1ac9 Not fixed yet, in case anyone was wondering if that commit fixed it. This is because maliit is not using layershell and KWin only lays out layer surfaces with regards to other layer surfaces Disregard the above. Actually I think rather the panel reserves size only for it's non-floating form and uses the window geometry of windows plasmashell knows about to defloat itself. But plasma doesnt know about the input panel window. After more testing I think there are two issues - with a floating horizontal panel part of the panel is covered because it only reserves space for its defloated height and relies on window geometries communicated with plasma-window-managment to defloat. Inputpanel (or layershell) windows are not reported. - with a non-floating horizontal panel thinks work correctly - a non-floating vertical panel does not have wrong struts. What maliit does is create a window as big as the screen (see also this comment here https://invent.kde.org/plasma/kwin/-/blob/master/src/inputpanelv1window.cpp#L90). This window's contents spans it fully horizontally but not vertically. So with a vertical panel there ends up being just not enough space. The first one we can fix inside the panel. The second requires maliit to use a different shell protocol than the current input_panel_surface as KWin can't resize maliit through that. (In reply to David Redondo from comment #15) > After more testing I think there are two issues > > - with a floating horizontal panel part of the panel is covered because it > only reserves space for its defloated height and relies on window geometries > communicated with plasma-window-managment to defloat. Inputpanel (or > layershell) windows are not reported. > - with a non-floating horizontal panel thinks work correctly > > - a non-floating vertical panel does not have wrong struts. What maliit does > is create a window as big as the screen (see also this comment here > https://invent.kde.org/plasma/kwin/-/blob/master/src/inputpanelv1window. > cpp#L90). This window's contents spans it fully horizontally but not > vertically. So with a vertical panel there ends up being just not enough > space. > > The first one we can fix inside the panel. Can we, though? Because it's intentional :-/ The issue with reserving the "correct" amount of space is that when we maximize a window that's going to maximize according to the floating panel strut, but then the panel de-floats, so the maximized windows have to get bigger, and that causes a quite ugly result. Thus the usage of the panel thickness, not considering floating margin, as the reserved area: it makes sure that the windows directly fill the correct amount of space immediately. > Can we, though? Because it's intentional :-/ We can do everything :D > The issue with reserving the "correct" amount of space is that when we maximize a window that's going to maximize according to the floating panel strut, but then the panel de-floats, so the maximized windows have to get bigger, and that causes a quite ugly result. Thus the usage of the panel thickness, not considering floating margin, as the reserved area: it makes sure that the windows directly fill the correct amount of space immediately. Hmm I think I can see what you mean. At first I though it all looks nice, the maximized windows are animated nicely to a new size. But I can sometimes see 1 pixel wide line flickering on the border. In my testing I would say it's 50/50 :/ *** Bug 479750 has been marked as a duplicate of this bug. *** In progress with https://invent.kde.org/plasma/kwin/-/merge_requests/6308. Git commit e4f9df54e6f6f7db493ac8e20fbcdac393bbd270 by David Edmundson. Committed on 30/08/2024 at 14:33. Pushed by davidedmundson into branch 'master'. inputmethod: Only align within availableGeometry if it fits An input panel in Overlay mode controls it's own size. If there's space we want to fit it centre aligned within the available space, but if it doesn't fit (i.e having a left panel and a full width keyboard) then centre aligning within the available space doesn't make sense. We would half overlap the panel and half go offscreen. This patch adjusts us to centre align to the output in that condition. M +9 -1 src/inputpanelv1window.cpp https://invent.kde.org/plasma/kwin/-/commit/e4f9df54e6f6f7db493ac8e20fbcdac393bbd270 |
Created attachment 140494 [details] Cover half the panel Fedora 34 with maliit-keyboard in a built-from-source Plasma Wayland session at 200% global scale. When the virtual keyboard appears, it overlaps half of my vertical left-side panel. See attached screenshot. I suspect that the goal is to avoid covering the panel, because when my panel is horizontal, it succeeds at avoiding covering it. However when my panel is vertical on either side of the screen, the virtual keyboard overlaps exactly half of it. Seems like some width calculation didn't take into account the scale factor or something.