SUMMARY *** Since today's update, I can't drag single windows from one virtual desktop to another> can't drag one window at a time from one virtual desktop to another. *** STEPS TO REPRODUCE 1. Set up 2 by 2 virtual desktops 2. Open a number of windows in one virtual desktop 3. Ctrl-F8 4. Position cursor over one window. (Perimeter is highlighted. NB I don't remember which setting gives this highlighting.) 5. Left click mouse and drag towards a different virtual desktop OBSERVED RESULT Perimeter of the window under the cursor is highlighted but, when clicking and dragging, all windows in the virtual desktop move together. EXPECTED RESULT Only the window under the cursor should move. (I believe this was the behaviour with Plasma 5.24) SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: KDE Neon (available in About System) KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION I don't know if this is related ..... I am also using an external monitor. I can drag windows between virtual desktops all on the laptop screen or all on the external monitor screen. However, if I try to drag windows from the laptop screen to external monitor (or vice versa) then, while in desktop grid view, the windows don't appear on the external monitor (when dragging from the laptop) or the laptop (when dragging from the external monitor). I can still drag single windows from laptop to external monitor or vice versa, when viewing any one virtual desktop. As always, thanks and regards
Created attachment 149719 [details] Cannot move a single window Cannot move a single window in desktop grid also.
Created attachment 149720 [details] Cannot move to a desktop with existing windows either, swaps them. Cannot move to a desktop with existing windows either, swaps them.
*** Bug 455280 has been marked as a duplicate of this bug. ***
Will be fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/2523
(In reply to Nate Graham from comment #4) > Will be fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/2523 Nate, Many thanks for this. Can you say roughly how long it may take for the fix to be released as an update? Best regards P
If all goes well, 6 days.
(In reply to Nate Graham from comment #6) > If all goes well, 6 days. Excellent. Again, many thanks. P
Don't thank me, thanks Marco who's fixing it, and also thank him again for the wonderful QML port of the Desktop Grid effect in Plasma 5.25 that fixed a ton of bugs and ensures it will be easily maintainable for a decade or more to come. :)
Git commit e04542995e45d29c4b4ef8664a6653afa112cfd6 by Vlad Zahorodnii, on behalf of Marco Martin. Committed on 16/06/2022 at 09:50. Pushed by vladz into branch 'master'. fix windows dragging in desktop grid Don't disable the main drag handler when canclosewindows is disabled, that one is not used to close windows but to drag them on other desktops or screens M +2 -1 src/effects/private/qml/WindowHeap.qml https://invent.kde.org/plasma/kwin/commit/e04542995e45d29c4b4ef8664a6653afa112cfd6
Git commit 99529e584b3605c040ad5ad88792a28a2c1ff263 by Vlad Zahorodnii, on behalf of Marco Martin. Committed on 16/06/2022 at 11:33. Pushed by vladz into branch 'Plasma/5.25'. fix windows dragging in desktop grid Don't disable the main drag handler when canclosewindows is disabled, that one is not used to close windows but to drag them on other desktops or screens (cherry picked from commit e04542995e45d29c4b4ef8664a6653afa112cfd6) M +2 -1 src/effects/private/qml/WindowHeap.qml https://invent.kde.org/plasma/kwin/commit/99529e584b3605c040ad5ad88792a28a2c1ff263
While that patch fixes it for dragging windows with the mouse cursor, it's still broken when using the touchscreen here, always dragging all windows of that virtual desktop.
*** Bug 455486 has been marked as a duplicate of this bug. ***
*** Bug 455488 has been marked as a duplicate of this bug. ***
*** Bug 455516 has been marked as a duplicate of this bug. ***
Issues: 1) Confirmation of Peter's problem 2) Additionally, current workspace no longer highlights ___________________________________________________________ As of 5.25 update, I began observing same behavior as this bug reporter (Peter) demonstrated in both videos. Additionally, in my initial installation of Stable User KDE Neon, about 10 days ago, the desktop grid view emphasized the current desktop at normal brightness, with all other windows dimmed. As you moved around the workspaces, the "brightened" desktop followed the cursor movement indicating the next desktop to be activated if clicked upon -- this highlighting no longer exists just as you can see in Peter's videos. All desktops now appear at full brightness with no implication of workspace change except by watching the cursor. This is the case irrespective of grid layout (same in a single row of windows, as well as a grid configuration). __________ System Information: Operating System: KDE neon 5.25 KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 Kernel Version: 5.13.0-51-generic (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Manufacturer: Framework Product Name: Laptop System Version: AB __________ Thank you for all the work you folks are doing. The gestures and overview are an especially welcomed addition!
(In reply to Brian M from comment #15) > Additionally, in my initial installation of Stable User KDE Neon, about 10 > days ago, the desktop grid view emphasized the current desktop at normal > brightness, with all other windows dimmed. As you moved around the > workspaces, the "brightened" desktop followed the cursor movement indicating > the next desktop to be activated if clicked upon -- this highlighting no > longer exists just as you can see in Peter's videos. > > All desktops now appear at full brightness with no implication of workspace > change except by watching the cursor. This is the case irrespective of grid > layout (same in a single row of windows, as well as a grid configuration). That's a different issue tracked at #453999
Created attachment 149935 [details] in action This is how it occurs in action.
(In reply to Fabian Vogt from comment #11) > While that patch fixes it for dragging windows with the mouse cursor, it's > still broken when using the touchscreen here, always dragging all windows of > that virtual desktop. this happening on both x11 and wayland?
(In reply to Marco Martin from comment #18) > (In reply to Fabian Vogt from comment #11) > > While that patch fixes it for dragging windows with the mouse cursor, it's > > still broken when using the touchscreen here, always dragging all windows of > > that virtual desktop. > > this happening on both x11 and wayland? I only tried Wayland so far, I can try X11 later today if that helps.
Testing a bit, i only kindof reproduced it, observing a slightly different behavior: it seems that both with mouse and touch, the first time i try to drag a window it never works, the second time i try to drag the same window, it works fine
reproduced on wayland (and wayland only) touch dragging is quite broken
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2550
Git commit c1a536a52739f92f40ce72421c54354db57b3fac by Marco Martin. Committed on 20/06/2022 at 10:11. Pushed by mart into branch 'master'. Fix dragging especially by touch The drag manager of a window now can take over from anything, so that the events to initiate a drag are not stolen by the tap handlers (fixes the drag starts only the second time is tried issue) On wayland drag by touch was completely broken by the supportsclosewindows check, now the touch drag handler is always active and the check of the property is done only when the drag is over M +2 -6 src/effects/private/qml/WindowHeap.qml https://invent.kde.org/plasma/kwin/commit/c1a536a52739f92f40ce72421c54354db57b3fac
Git commit 2eb0c67b0bc7ee62e37cb510fafeec66a012b53f by Vlad Zahorodnii, on behalf of Marco Martin. Committed on 20/06/2022 at 10:16. Pushed by vladz into branch 'Plasma/5.25'. Fix dragging especially by touch The drag manager of a window now can take over from anything, so that the events to initiate a drag are not stolen by the tap handlers (fixes the drag starts only the second time is tried issue) On wayland drag by touch was completely broken by the supportsclosewindows check, now the touch drag handler is always active and the check of the property is done only when the drag is over (cherry picked from commit c1a536a52739f92f40ce72421c54354db57b3fac) M +2 -6 src/effects/private/qml/WindowHeap.qml https://invent.kde.org/plasma/kwin/commit/2eb0c67b0bc7ee62e37cb510fafeec66a012b53f
*** Bug 455479 has been marked as a duplicate of this bug. ***
Just updated to Build 64, and everything working again. I notice also that the way windows move across the different virtual desktops on the different screens has also changed and is, I think, now more intuitive and convenient than before. Thanks again to Nate, Marco, Vlad, and everyone else involved. A beautiful DE.
Hooray!