Initial report: BUG 453943 SUMMARY After the recent QML rewrite of the desktopgrid effect, the animation when moving windows on the grid is now always using the first desktop (the upper-left one) as the window's origin instead of its current/previous desktop. See https://youtu.be/A0ydBC6tvUQ STEPS TO REPRODUCE 1. set up a grid 2. open some windows on each desktop 3. move windows between desktops on the grid SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION - KWin built from 09ba8729fc12 (current master) using the modified PKGBUILD of the Arch repos - kdecoration built from 4123ec8c1993 (current master) using the modified PKGBUILD of the Arch repos - plasma-wayland-protocols built from 26fb07b9f8d3 (current master) using the modified PKGBUILD of the Arch repos - the remaining dependencies were all from the official Arch repos
Since my report of this issue only focused on X11, let me just quickly add that moving windows on Wayland is completely broken. Moving a window will always move it to the first desktop without an animation, but when going to the first desktop, the window has instead been ("successfully") moved to the desktop which it has been dragged onto. However, there also seems to be an issue with the visibility of the window afterwards and it is hidden in some cases, so something must be broken with the window animation state on Wayland after moving it.
*** Bug 454073 has been marked as a duplicate of this bug. ***
Looking at similar behavior on Wayland as described in Bug 454073. Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.24.90 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Graphics platform: Wayland
*** Bug 454150 has been marked as a duplicate of this bug. ***
*** Bug 454153 has been marked as a duplicate of this bug. ***
*** Bug 455726 has been marked as a duplicate of this bug. ***
*** Bug 455817 has been marked as a duplicate of this bug. ***
Copying from my report (455817) since the reasoning for no additional animation is important: With the reimplementation in 5.25 and the fix in 5.25.1, when you move windows between workspaces in the new Grid effect, they animate really strange. You drag a window to another workspace – this really drags its miniature preview – and drop it to this other workspace. This initiates a fast slipping process from its current workspace to the new. But you have just dropped it there! Instead of just appearing there, it animates like you never dragged it from its original workspace over to the other one. Watch a video about how the old effect handled this: https://youtu.be/_w_ksgcNnYc?t=23 EXPECTED RESULT The window drops to the new workspace and is just appearing there. The old effect handled this with no explicit animation other than for an sudden new window in Grid (like when an error is appearing or such). It looked more natural than the current slipping between workspaces. Again: You have already dragged it there, it shouldn’t move from its original position! KDE Plasma Version: 5.25.1 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5
Fully agree with comment 8.
Found another screencast about how the old implementation handled this: https://www.youtube.com/watch?v=7pwoGfaJjpI&t=32s Note the satisfying transition from mini preview to medium preview of the browser window when it’s dragged over to an empty workspace. It’s always the window you drop, it doesn’t disappear in mini form and comes back bigger but it transforms from the position you drop it to its new size.
Please fix this. 5.25.2 not only shows a broken animation when moving windows, but after a window has been moved to a different desktop, it's shown incorrectly on the first virtual desktop until the effect gets reopened. Sometimes, windows are even placed on a totally different virtual desktop, without even moving them
After moving a window, its content also doesn't seem to be updated anymore. Eg. when watching a video. It only gets updated for one frame when moving the mouse over it again.
(In reply to bastimeyer123 from comment #12) > After moving a window, its content also doesn't seem to be updated anymore. > Eg. when watching a video. It only gets updated for one frame when moving > the mouse over it again. Looks like no windows contents at all get updated on different virtual desktops when showing the grid, so this is not related to moving windows.
> After moving a window, its content also doesn't seem to be updated anymore. Can confirm, I've opened a separate bug report for that: bug 456280
Created attachment 150757 [details] broken window move animation How is it possible that this bug hasn't gotten more attention? The QML re-implementation has been merged two months ago, and 5.25 has been released more than one month ago, which means that this broken mess has been unfixed and released as stable for a very long time now. The attached video is recorded with kwin built from the Plasma/5.25 branch and commit 84277885b944.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2859
*** Bug 456436 has been marked as a duplicate of this bug. ***
Git commit b01ea99c0170d34cb0965b05db9b27c070ff1eea by ivan tkachenko. Committed on 12/09/2022 at 22:49. Pushed by ratijas into branch 'master'. effects/desktopgrid: Restore position correctly when dropping a window This required a bit of a magic on the WindowHeap side to store and restore global position of a WindowHeapDelegates' window thumbnails. An additional property bool animationEnabled on a delegate level enables the heap to restore position without playing unneeded initial animation, just like the heap itself. Windows that are being dragged or already returning form a drop are positioned higher than others on a z-stack. M +4 -0 src/effects/desktopgrid/qml/DesktopView.qml M +7 -0 src/effects/desktopgrid/qml/main.qml M +24 -0 src/effects/private/qml/WindowHeap.qml M +74 -8 src/effects/private/qml/WindowHeapDelegate.qml https://invent.kde.org/plasma/kwin/commit/b01ea99c0170d34cb0965b05db9b27c070ff1eea
Created attachment 152469 [details] Screenrecording (5.25.90 commit f343f3fb80284a8e402b39924c789b629806ac62) Unfortunately, I can still reproduce it in case of two screens. Please see the attached screen recording. Though, the animation doesn't start necessarily now in the upper left VD.
Created attachment 152470 [details] kWin Support Info (5.25.90 commit f343f3fb80284a8e402b39924c789b629806ac62)
I meant 5.26.80 instead of 5.25.90 in the posts above. Tested on the current master branch.
Multi-screen issues of Desktop Grid and Overview are a whole different topic, their implementation uses multiple actual Window objects, and interaction between them is only possible through a C++ backend model or something like that. tl;dr let's have a separate bug report for tracking multi-screen problems.