When I hid a gift-shopping window, I moved it to the far bottom of the screen, and when I searched it back later I had to use alt-tab to find it because it disappeared from the plasma task bar. My panels are on top of the screen, thus making this bug possible. Reproducible: Always Steps to Reproduce: 1. Move tasks bar to top 2. Move a window below the screen, leaving only a part of its decoration visible 3. Look at the task bar Actual Results: Window is no more accounted on the right screen Expected Results: Window should be still counted on its screen… I'm using two screens side by side with nVidia proprietary driver. I can't reproduce the bug on a single-head system. The xrandr configuration does not create «invisible» virtual screen space : both screens are 1920x1080 with no offset.
not kwin. Eike, this might be in kwindowsystem or not a bug at all (taskbar only showing windows on this screen and only the client geometry is supposed to be considered "this screen")
I need a re-test with the completely new Task Manager backend in 5.7, the 5.6.x code is no longer being worked on.
I don't have enough time to build and test Plasma 5.7 right now, I'll wait for the Debian sid packages or try to fix up a test machine with a second screen. Sorry for the wrong category, I though it was kwin that exposed the list of windows to the taskbar.
Nah, basically the Task Manager gets screen geometry and window geometry and checks whether they intersect.
If you literally test KWindowInfo::geometry() and not KWindowInfo::frameGeometry(), I know why this happens ;-)
:) Thomas, mind having a look at the code in plasma-workspace/libtaskmanager/xwindowstasksmodel.cpp, specifically XWindowsTasksModel::Private::screen()? It looks like it might need frameGeometry() indeed, but perhaps you see something else too.
The function prefers lower screens, ie. if a window intersects screen 0 & 1, it will determine the window on screen 0, even if there's only a single intersecting pixel. Windows can be legally on multiple screens because they either cross the border or because the screens overlap ("cloned") Even if you want to ignore the latter case and only support bijective assignments, you might want to test the (frame)geometry().center() (which implies the biggest share on regular™ setups) instead. Depending on the usecase, you may also first test availableGeometry() to ensure you do not estimate a window on a screen where it's (completely) covered by (strutting) panels if it's pot. also on another screen. (It can still be below non-strutting panels despite such test, though) For a general geometry comparism (is this window on this screen) you should test the ::frameGeometry(), users tend to consider them a unit.
Change up for review: https://phabricator.kde.org/D1925
Git commit 3b1618c5590b85785d84a7d27787ba43ef7486b2 by Eike Hein. Committed on 17/06/2016 at 08:00. Pushed by hein into branch 'Plasma/5.7'. Improve window-on-screen intersection test. Summary: Changes the test from "client rect intersects with screen rect" to "screen that contains the center of the client+deco rect or screen this point is cloest to". This is a behavior change also vs. libtaskmanager-old and should address user bug reports like bug 364280. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1925 M +19 -2 libtaskmanager/xwindowtasksmodel.cpp http://commits.kde.org/plasma-workspace/3b1618c5590b85785d84a7d27787ba43ef7486b2