Summary: | [Desktop grid] Window re-arranging animation played when dragging whole VD to another empty VD | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | postix <postix> |
Component: | effects-overview | Assignee: | ratijas <me> |
Status: | CONFIRMED --- | ||
Severity: | minor | CC: | breakingspell, nate, titouan-camus |
Priority: | NOR | ||
Version First Reported In: | 6.0.1 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Screenrecording: With MR2965
Screenrecording: Without MR2965 Desktop Grid behavior in 11/28 master |
Description
postix
2022-09-16 15:58:09 UTC
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 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
|