SUMMARY After a certain amount of time, applications (kwin interaction?) do not to allow me to drag them above the topmost panel when simulating a MacOS or older Gnome setup. Applications without native title bar and borders (Google Chrome for example) do allow themselves to be dragged successfully. In my dual configuration I have my primary screen below my secondary screen in a vertical stacked layout. This puts my secondary monitor above the topmost panel. What's very odd is this is not an issue until a few hours pass by. All of the sudden I am unable to drag windows to my secondary monitor. If I use the meta key I can drag them, but the second I adjust them otherwise they "snap" to my primary screen. If I log out and log back in, the cycle repeats (eventually). Locking the screen is not a trigger to cause the bug. STEPS TO REPRODUCE 1. Configure dual monitors in a vertical "stacked" configuration. 2. Use lattedoc with a top panel. 3. Use desktop normally for an undetermined amount of time (few hours). OBSERVED RESULT Cannot drag windows to secondary screen above topmost panel. EXPECTED RESULT Windows should be able to be freely positioned on any screen regardless of the layout of lattedoc or multi-monitor configuration. SOFTWARE/OS VERSIONS OpenSUSE Tumbleweed KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Graphics Platform: X11
1. Isnt that the default KWin snapping behavior? 2. By dont letting you move them dont you mean that they become maximized when touching the latte top panel? 3. If you use a plasma top panel with visibility "Always Visible" dont you get the exact same result? 4. If you change Visibility mode for your top latte panel to Windows Go Below isnt that enough to let you move your windows upwards?
5. If you disable: Plasma SystemSettings -> Workspace Behavior -> Screen Edges -> Maximize: Windows dragged to top edge , does it make any difference?
(In reply to Michail Vourlakos from comment #1) > 1. Isnt that the default KWin snapping behavior? Regardless of defaults, this "works" for a while, then doesn't work. More details on this under my #4 reply below. > 2. By dont letting you move them dont you mean that they become maximized > when touching the latte top panel? If I continue to drag the window above the lower primary monitor it will become maximized in the top monitor (more unexpected behavior). Once it is maximized in the top monitor, if I un-maximize the window and then attempt to position the window in the top monitor screen space, it will snap back to the lower primary monitor. > 3. If you use a plasma top panel with visibility "Always Visible" dont you > get the exact same result? I can test this behavior later today, but this is not my normal non-lattedock plasma setup. > 4. If you change Visibility mode for your top latte panel to Windows Go > Below isnt that enough to let you move your windows upwards? Yes, toggling this, waiting for the topmost panel to disappear does let me drag windows freely to my topmost monitor screen. After this procedure, toggling the back to "always visible" restores expected functionality as well. I can snap windows up against the top most panel, maximize them in against the panel in the expected correct screen, and also drag them into my topmost monitor screen space.
> > 4. If you change Visibility mode for your top latte panel to Windows Go > > Below isnt that enough to let you move your windows upwards? > > Yes, toggling this, waiting for the topmost panel to disappear does let me > drag windows freely to my topmost monitor screen. > > After this procedure, toggling the back to "always visible" restores > expected functionality as well. I can snap windows up against the top most > panel, maximize them in against the panel in the expected correct screen, > and also drag them into my topmost monitor screen space. I looked the Plasma panels code: https://github.com/KDE/plasma-workspace/blob/master/shell/panelview.cpp#L1088 , for your scenario plasma panels disable AlwaysVisible visibility mode and force WindowsGoBelow. So as long as you enable WindowsGoBelow for your latte panel you will get exact the same behavior. This is KWin bug/responsibility, I could also blacklist the case as plasma is already doing. By reading the plasma devs code it is clear that using AlwaysVisible visibility in your scenario can break multiple things and this is why they have blacklisted it.
(In reply to Michail Vourlakos from comment #4) > > > 4. If you change Visibility mode for your top latte panel to Windows Go > > > Below isnt that enough to let you move your windows upwards? > > > > Yes, toggling this, waiting for the topmost panel to disappear does let me > > drag windows freely to my topmost monitor screen. > > > > After this procedure, toggling the back to "always visible" restores > > expected functionality as well. I can snap windows up against the top most > > panel, maximize them in against the panel in the expected correct screen, > > and also drag them into my topmost monitor screen space. > > > I looked the Plasma panels code: > https://github.com/KDE/plasma-workspace/blob/master/shell/panelview. > cpp#L1088 , for your scenario plasma panels disable AlwaysVisible visibility > mode and force WindowsGoBelow. So as long as you enable WindowsGoBelow for > your latte panel you will get exact the same behavior. > > This is KWin bug/responsibility, I could also blacklist the case as plasma > is already doing. By reading the plasma devs code it is clear that using > AlwaysVisible visibility in your scenario can break multiple things and this > is why they have blacklisted it. I've switched from lattedoc back to regular plasma panels the past couple of days. I've made sure to use a top panel on my primary lower screen for a global application menu, similar to my previous lattedoc layout. However, I cannot trigger the odd behavior by dragging windows to the top secondary screen. Everything has been functioning as expected with regular panels. My top panel is not set to autohide or anything either. I'm personally going back to plasma panels and removing a "top panel" entirely for daily use here, so I won't be of much more use on this bug report. Should further testing be needed, it should be easy to fake my vertical monitor layout in a true side-by-side monitor desk configuration. Thanks!
Git commit 80fa1022a57f5cdb41a6d40e1603987034095098 by Michail Vourlakos. Committed on 12/12/2021 at 12:34. Pushed by mvourlakos into branch 'v0.10'. multiscreen:disable struts under x11 when overlap --when multiple screens placement have edges that overlap with each other, at that edges struts must be disabled to provide much better windows behavior. For example when dragging a window between such screens and there is an AlwaysVisible panel or dock between them. FIXED-IN:0.10.5 M +2 -0 app/screenpool.cpp M +1 -0 app/screenpool.h M +68 -7 app/view/visibilitymanager.cpp M +3 -1 app/view/visibilitymanager.h https://invent.kde.org/plasma/latte-dock/commit/80fa1022a57f5cdb41a6d40e1603987034095098
Git commit ca83433ce0a2bf67decb66bc9e0620830c9884a4 by Michail Vourlakos. Committed on 12/12/2021 at 12:39. Pushed by mvourlakos into branch 'master'. multiscreen:disable struts under x11 when overlap --when multiple screens placement have edges that overlap with each other, at that edges struts must be disabled to provide much better windows behavior. For example when dragging a window between such screens and there is an AlwaysVisible panel or dock between them. FIXED-IN:0.10.5 M +2 -0 app/screenpool.cpp M +1 -0 app/screenpool.h M +68 -7 app/view/visibilitymanager.cpp M +3 -1 app/view/visibilitymanager.h https://invent.kde.org/plasma/latte-dock/commit/ca83433ce0a2bf67decb66bc9e0620830c9884a4