I have a two monitor setup. Laptop screen eDP1 is below the HDMI screen. Xrandr is like this: xrandr --output eDP1 --auto --below HDMI1 --output HDMI1 --auto --primary Large Monitor on HDMI is the primary one, it has the taskbar/panel 100% of the width. The panel is at the bottom edge of the HDMI monitor. The Laptop Monitor on eDP1 does not have any panels, just empty. When I try to move a window using my mouse from the top monitor, through the panel, to the bottom monitor, the window goes but gets stuck at the panel. So the window is essentially trapped in the top monitor. If I use the Move To Screen - Screen Two (eDP1) command on the top left icon of that window, the window moves. Hope I'm not the only one using Top-Bottom monitor configurations :) Reproducible: Always
Created attachment 101529 [details] Screenshot that shows the problem
You should be able to move the window using Alt+ left mouse button. Overall that's a protection. One cannot move the window decoration underneath a panel. This is the intended behavior to make sure that you cannot move a window out of view and that one always can move the window. Not sure what to do here as changing that could become dangerous by breaking the protection.
Thanks Martin for the response and the ALT+LEFT_MOUSE tip. That helps as a workaround although one that requires an extra step each time you want to move a window. In MS Windows desktops no such problem exists. I do not understand what you mean that it's a protection. In years of Windows use, never faced such issue. By the time the last pixel row comes to the panel it jumps to second screen.
Emre, I'm curious - does this problem still happen if you move the panel to the top? It sounds as if it is related to the panel trapping a mouse event.
Hi Luke, no, when the panel is at the top, that problem does not exist. Windows can freely move between monitors. The workaround that Martin has given works well. If you click ALT before you click the window titlebar, then you can move the window to the other monitor passing under the panel.
(In reply to Emre from comment #5) > Hi Luke, no, when the panel is at the top, that problem does not exist. > Windows can freely move between monitors. > The workaround that Martin has given works well. If you click ALT before you > click the window titlebar, then you can move the window to the other monitor > passing under the panel. As I suspected then. You'll find that the panel blocks any window being dragged by the titlebar, regardless of where the panel is. The question is if this behaviour should be removed or not.
> You'll find that the panel blocks any window being dragged by the titlebar, regardless of where the panel is. The question is if this behaviour should be removed or not. This is the protection I talked about. It is the intended behavior and will not be changed in general. The only question is whether we can make it work better in the multi-screen case.
*** Bug 374263 has been marked as a duplicate of this bug. ***
*** Bug 376168 has been marked as a duplicate of this bug. ***
I created a patch for bug #371199 which might address also this problem: https://phabricator.kde.org/D6562 I'm not sure whether it can also fix this problem here as it is slightly different.
Git commit 14c8440f11f9af48e63ca0fcf05ee7988f445b9a by Martin Flöser. Committed on 11/07/2017 at 15:51. Pushed by graesslin into branch 'master'. Restrict move resize area only on the screen the strut window is on Summary: By allowing panels between screens in 5.8 to have a strut we created a "regression" in KWin. KWin always was wrong, just we didn't notice as neither Plasma nor previously Kicker set a strut on panels between shared screen edges. The strut is created from the edge of the overall screen setup. This means a panel on the left edge of a screen on the right has the strut starting from the left screen. KWin uses the strut to restrict the move resize area: a window decoration is not allowed to go below a strut. Thus it becomes impossible to move the window from the right to the left screen. This change tries to solve this problem by only restricting the move area on the screen the window with the strut is on. E.g. if the window is on the right screen, the left screen is not affected. Thus it's possible again to move a window from one screen to the other as the added test case shows. Unfortunately there are still corner cases where this won't work correctly. If the window is on both screens this won't work. It is also a rather heavy change for KWin and thus it's targeted for master and not for the 5.10 or the 5.8 branch. If we notice that the patch works well and doesn't create further issues, it should be considered for backporting. Related: bug 371199 FIXED-IN: 5.11 Test Plan: Added test case Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D6562 M +151 -19 autotests/integration/struts_test.cpp M +4 -0 geometry.cpp https://commits.kde.org/kwin/14c8440f11f9af48e63ca0fcf05ee7988f445b9a
Did 5.11 fix the issue?
If you can provide the information requested in comment #12, please add it.
I can freely move windows now over the taskbar. So I think the issue is resolved. Latest KDE in Arch, I guess it's 5.12.2.
Setting to fixed as of latest comment
*** Bug 391279 has been marked as a duplicate of this bug. ***