STEPS TO REPRODUCE 1. Open the grid view 2. Drag all windows of a VD together to another empty VD. In my case I had like 6 windows opened OBSERVED RESULT The windows appear to re-arrange to the very some positions on drop. EXPECTED RESULT The windows do not re-arrange but simply drop at their right spots in the same spacial configuration as they are dragged. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220914 KDE Plasma Version: 5.26.80 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.5 Graphics Platform: Wayland
Can confirm.
I believe this is due to an incorrect usage of a TextField API in QML/QtQuick: > onTextChanged: { > effect.searchText = text; > heap.resetSelected(); > heap.selectNextItem(WindowHeap.Direction.Down); > } > Binding { > target: searchField > property: "text" > value: effect.searchText > } My gut feeling tells my this Binding should've never existed. and onTextEdited should've been used in the first place. There's also the Window View effect, which is like Overview but should be merged with it. And there's a similar SearchField, but with a comment: > // Binding loops will be avoided from the fact that setting the text to the same won't emit textChanged which supports my theory that developers simply didn't know the trick. Also, the root cause here is this function: > function start() { > animationEnabled = true; > organized = true; > searchField.text = ""; > } Clearly, it resets search text too late.
...not to mention that the `searchText` property exists only in WindowViewEffect class, but not in OverviewEffect :-\ how did it even…
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2965
Created attachment 152148 [details] Screenrecording: With MR2965 Short feedback: I have tested the current state of MR2965, but unfortunately it hasn't fixed the issue for me yet. Please see the screen recording.
Created attachment 152149 [details] Screenrecording: Without MR2965
> Short feedback: I have tested the current state of MR2965, but unfortunately it hasn't fixed the issue for me yet. Please see the screen recording. I must have linked the wrong BUG number. That MR fixes the rearrangement after searching and not clearing the search text. It should've been BUG 459202. Thanks, I'll correct the commit description now. The rearrangement I see here is likely because desktops get recreated, and the new window heap instance re-layouts its content. It really sucks that it is not deterministic as it should be.
*** Bug 486202 has been marked as a duplicate of this bug. ***
This is still an issue in latest master (6.3), provided video clip demonstrating this. The clip demonstrates normal window drop behavior, and then attempts to perform this drop action on the entire desktop's selection. The two methods should ideally behave as similarly as possible. When an entire selection of a desktop's windows are dropped into a Desktop Grid tile, the windows will animate rearranging themselves upon drop, without actually changing positions. In addition to the rearrangement animation, the drop animation is also missing, evident in the clip. This results in an abrupt pop to the destination desktop, when the windows should "glide" to their destination or back as a whole, as individual windows do.
Created attachment 176269 [details] Desktop Grid behavior in 11/28 master