After changing from the external screen to the laptop screen or vice versa, maximized windows no longer take the panel into account: They become as large as the entire screen, with their bottom part being covered by the panel. Reproducible: Always Steps to Reproduce: 1. Start a session, on one of two screens of different resolutions 1a. Have a panel at the bottom, and no other panel 2. Use xrandr or whatever to move things to the other screen 3. Maximize any window Actual Results: The bottom part of the window is covered by the panel. Expected Results: Maximizing should take the panel into account, and should resize the windows such that the panel doesn't cover any part of them. This is a very bad regression compared to KDE4. I now have to restart Plasma several times a day to fix the panel geometry... I am using Debian testing and Qt 5.5. Whether this bug is in Plasma or kwin I don't know.
Can you run "xprop" and click on the panel please also output of xrandr before and after step 2.
Created attachment 94836 [details] xprop of broken panel
Created attachment 94837 [details] xrandr before step 2
Created attachment 94838 [details] xrandr after step 2
Created attachment 94982 [details] Extra xrandr/xprop I'm having the same problem (except on version 5.4.2 on arch packages), figured I might add my data as well.
*** Bug 353693 has been marked as a duplicate of this bug. ***
I have a bit different steps to reproduce (originally reported in https://bugs.kde.org/show_bug.cgi?id=353693 - see also xrandr and xprops output attached there): just switch between two displays and on the newly enabled display the windows do not respect the panel. I also found a workaround - kill and restart just the plasmashell process.
Or, another non-drastic workaround, open the panel's settings > more settings > Auto hide, then click outside so the panel settings closes. Reopen the panel settings > more settings > keep visible.
Hello, this bug is still present in KDE 5.5.0 and qt 5.5.1 on Archlinux with Intel Broadwell Chip. Please fix this, it is a very annoying bug for my daily work. Thanks!
The same problem happens for panels added to the secondary screen in a dual-screen setup.
This is still a problem in the version in Debian right now (plasma-desktop 5.4.3). It is one of a series of bugs that makes working with KDE on a dynamic multi-screen setup pretty much impossible. I think all the information that has been asked for has been provided. Why is this bug still "NEEDSINFO"?
Rather embarrassingly, this issue persists with Plasma 5.6 (from KDE experimental). Furthermore, nobody even bothered to to unset the NEEDSINFO flag after all information htat has been asked for, has been provided. I will now set this bug to CONFIRMED. Maybe that helps?
*** This bug has been marked as a duplicate of bug 348043 ***
Fvwi, bug #360828 has a zero strut where the other ones seem to have a negative one. Latter are likely to be due to miscalculation (window, rather than root geometry) in a multiscreen setup but former is just plain broken (it's a singlescreen setup)
Yes, I'm aware. I marked these as duplicates cause in both cases the cause is the same - wrong struts. So if/when someone will investigate the code for struts, I'm hoping that someone will also test it and/or have it tested in multiscreen setup, killing two bugs with the same cause at once.
The panelview uses KScreen & QScreen concurrently what bears a great potential for races (kscreen reads randr event, fires signal, panelview acts, qscreen reads event and updates its members) WIth the local screen implementation in KWin (Martin discarded QScreen; no idea about kscreen, but half of the "help, my desktop is weird" forum posts relate to it...) we've 3(!!!) screen implementations around... but screens aren't relevant to smartphones, so why bother. *shrug*
https://git.reviewboard.kde.org/r/125451/
Kwin does use QScreen (indirectly) QDesktopWidget (which kwin uses) was ported to be a thin layer over QScreen API. You're right about the cause of the screen problem, problem is it it's not as simple as porting to: const QRect thisScreen = corona()->screenGeometry(containment()->screen()); as we're calling updateStruts() from both a QScreen related signal and a kscreen related one. The first one we can't port from as easily. Qt 5.6 brought fixes we need, which means Plasma 5.7 can finally use one (well, two if you count Corona) API. Yes the situation is broken, but it does have nothing to do with smartphones so can you avoid the snarky comments.
Afaics, QDesktopWidget is only used (as a single remainder, looks like an oversight) in scripting/workspace_wrapper.cpp and some kcms.
QDesktopWidget is also broken, at least in Qt 5.5 and (if I read the code correctly) still in 5.6: <https://bugreports.qt.io/browse/QTBUG-52101>