Summary: | "Windows can cover" does not seem to work for me | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Gunter Ohrner <kdebugs> |
Component: | Panel | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | kde, nate, notmart, notuxius, sergio.callegari |
Priority: | NOR | ||
Version: | 5.9.2 | ||
Target Milestone: | 1.0 | ||
Platform: | Neon | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
kCalc does not cover the "Windows can cover"-panel in the lower right screen corner. Also maximized windows never cover it, the panel always stays in front.
xprop of the "always on top" "Windows can cover" panel new panel with kcalc beneath it new panel with maximized kate beneath it xprop of new panel |
Description
Gunter Ohrner
2016-02-20 11:03:31 UTC
Created attachment 97311 [details]
kCalc does not cover the "Windows can cover"-panel in the lower right screen corner. Also maximized windows never cover it, the panel always stays in front.
Please run xprop and click on the panel Then attach the output. This can also happen if one of the applets in the panel is marking itself as "needs attention", at which point we deliberately bring ourselves to the front. If you make a new empty panel, does that work correctly? (In reply to David Edmundson from comment #2) > If you make a new empty panel, does that work correctly? No - or I'm doing something wrong. ;) I created a completely new, empty panel and configured it as "Windows can cover". All windows will be displayed beneath it, even in maximized mode. I'll attach the xprop output. Created attachment 97555 [details]
xprop of the "always on top" "Windows can cover" panel
can't reproduce on master xprop output is quite strange as it shows the old plasma icon as the window icon, suggests some weird mixup of kde4/kf5 environment Nah, that must be just the oxygen icon set. It must be Plasma 5 as it has _KDE_NET_WM_BACKGROUND_CONTRAST_REGION xprop doesn't list any struts, so that's doing the right thing. What window manager do you use? have you tried dragging a window so it covers the panel? (or clicking maximise0 note that windows still snaps along the panel edge and windows wont' automatically cover it for no reason. Right, I'm using the Oxygen icons. (The panel does not actually seem to show/display its icon anywhere btw. The panel menu is just a three-bars-symbol.) I'm using kwin: ii kwin-x11 4:5.5.4-0ubuntu1~u amd64 KDE window manager, X11 version Windows dragged to where the panel is or maximized windows always move behind the panel, just as the first attachment shows. This also happened with the new panel I created, from which I took the xprops. Created attachment 97647 [details]
new panel with kcalc beneath it
Created attachment 97648 [details]
new panel with maximized kate beneath it
Created attachment 97649 [details]
xprop of new panel
Still experiencing this with Plasma 5.9.2 KDE Neon packages - any news on this issue? Can't reproduce in: Plasma: 5.12.2 Apps: 17.12.2 Frameworks: 5.43.0 Qt: 5.10.1 Kernel: 4.14.22-1-MANJARO OS: Netrunner Rolling Video: Intel 4400 xf86-video-intel 1:2.99.917+812+g75795523-1 Screen: 1600x900 It's still happening for me with basically the same software environment. (KDE Neon 5.12.2) I'm also currently running: * Plasma: 5.12.2 * Apps: 17.12.2 * Frameworks: 5.43.0 I'm not quite sure about the included libqt5 (I get version numbers 5.9.4 as well as 5.10.0 for different packages) and I'm using a slightly older Kernel... Reproducing it with: Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-48-generic OS Type: 64-bit very nasty, because together with bug 351175 this basically means that having more than the bottom panel on dynamic multi screen configurations is looking for trouble, because you will almost invariably getting panels that cover useful windows in critical bits like scrollbars, etc. Moving the bug to "confirmed state" as multiple users appear to be experiencing it. If no resources can be available for fixing this, please consider removing/disabling/hiding functionalities that have anyway been broken for many years as they just confuse the user. Wonder if this may have to do with panels added with "old" versions of plasma 5. @Gunter: can you still reproduce this issue in Plasma 5.27? If you can, can you try deleting and recreating your panel anew? @everyone else: can you please submit a new bug report with your issues, if you're still able to reproduce them in Plasma 5.27? I ask because they are highly likely to have a different root cause from when Gunter is reporting here. Thanks a lot! Seems to work fine now for the panels I used for testing. Plasma Workspace 4:5.27.8-0xneon+22.04+jammy+release+build41 Plasma Framework 5.110.0-0xneon+22.04+jammy+release+build49 (KDE neon) |