https://bugs.kde.org/show_bug.cgi?id=496646

            Bug ID: 496646
           Summary: [Desktop Grid] Regression in dropped window animations
    Classification: Plasma
           Product: kwin
           Version: git master
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: effects-overview
          Assignee: kwin-bugs-n...@kde.org
          Reporter: breakingsp...@gmail.com
  Target Milestone: ---

This directly follows BUG 495444 and
https://invent.kde.org/plasma/kwin/-/commit/2e0b33eae4588a829e64495efbb27a25da311190

SUMMARY
With the Overview's Desktop Bar being addressed in the previous case, the fix
to WindowHeapDelegate.qml regressed window placement on the expanded Desktop
Grid in the Overview effect. 

Windows dragged into the target desktops stop animating and do not ease into
their defined position. 
Can reproduce on X11 and Wayland with 4 desktops in 2x2 grid, recordings
attached.

STEPS TO REPRODUCE
1. Sign into new session (X11/Wayland)
2. Engage Overview (Meta+W) and add four Virtual Desktops in the Desktop Bar.
3. In Virtual Desktop KCM, increase Row count to 2.
3. Drag and drop a window to any desktop using the expanded Desktop Grid.
4. Observe the window behavior, where the dropped windows do not animate when
they should.

OBSERVED RESULT
Windows stop animating when dropped in the Desktop Grid. 

EXPECTED RESULT
Windows should "ease" over to their designated place. 

SOFTWARE/OS VERSIONS
KDE Plasma Version: master branch
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0

ADDITIONAL INFORMATION

I tried to move the code fix from WindowHeapDelegate.qml to DesktopBar.qml (in
DropArea) or main.qml of Overview, but realized rather quick it doesn't work
this way, the behavior is driven here by WindowHeapDelegate. 

I then tried to restrict the fix using an extra if() check in
WindowHeapDelegate.qml to only apply to windows dropped in the Desktop Bar's
container, but I don't think this is possible due to the QML context not being
nested as parent/child. I'm reading in general that chaining contexts like this
is not best practice, anyway.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to