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

Vlad Zahorodnii <vlad.zahorod...@kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Latest Commit|                            |https://invent.kde.org/plas
                   |                            |ma/kwin/-/commit/15b8fbe604
                   |                            |4a0fd3cb66af78d7e4e44338be5
                   |                            |b58
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #3 from Vlad Zahorodnii <vlad.zahorod...@kde.org> ---
Git commit 15b8fbe6044a0fd3cb66af78d7e4e44338be5b58 by Vlad Zahorodnii.
Committed on 21/11/2023 at 20:26.
Pushed by vladz into branch 'master'.

Preserve relative order of transient siblings

If a constraint indicates that window A must be below window B but it's
not the case at the moment, the workspace will move window A right after
window B.

This can invert the relative order of transient siblings, for example
let's say that there are three constraints

- A <- B (window A must be below window B)
- A <- C
- A <- D

and the unconstrained stacking order looks as follows: [B, C, D, A]. The
final constrained stacking order is expected to look as [A, B, C, D],
but currently it's [A, D, C, B] instead:

- starting stacking order: [B, C, D, A]
- apply A <- B constraint: [C, D, A, B]
- apply A <- C constraint: [D, A, C, B]
- apply A <- D constraint: [A, D, C, B]

In order to fix this issue, this patch makes the workspace traverse the
constraint graph in the reverse order. In addition to that, it ensures
that the relative order of transient siblings in unconstrained stacking
order is preserved in the constrained one.

M  +16   -7    src/layers.cpp

https://invent.kde.org/plasma/kwin/-/commit/15b8fbe6044a0fd3cb66af78d7e4e44338be5b58

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

Reply via email to