SUMMARY *** The minimal overlap placement method should take stacking order into account and prefer not to overlap windows that have recently been active. *** STEPS TO REPRODUCE 1. Select System Settings > Window Management > Window Behavior > Advanced > Window Placement > Minimal Overlapping. 2. Have a bunch of windows open covering most of the screen. 3. Activate a window towards the bottom/right of the screen. 4. Open a new window large enough not to fit into any free space. OBSERVED RESULT The new window is placed in the bottom/right corner, covering the recently active window. EXPECTED RESULT The new window is placed such that overlap with the most recently active window is avoided and a different part of the screen will be occupied instead. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.0-arch1-1 (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION I've been observing that the minimal placement option will often position new windows right on top of the one that has just been worked in. I would imagine that for most use cases it would be preferable to keep recently active windows visible, and accept overlap windows that have been unused for longer instead. If understand the minimal overlap placement algorithm (https://invent.kde.org/plasma/kwin/-/blob/master/src/placement.cpp#L198 ?) correctly , the search does not take window's stacking/last-activated rank into account in computing the overlap, but rather will traverse the screen from left to right and top to bottom and sum up the potential overlaps with all windows equally. However, there is apparently already a penalty for windows set as keep above: https://invent.kde.org/plasma/kwin/-/blob/master/src/placement.cpp#L262 My proposal is to add a similar penalty for recent activity, either a simple extra condition for the one window that has been the most recently active, or a continuous rank based on stacking order. This would make the placement method somewhat "smarter" i.m.o.
> (https://invent.kde.org/plasma/kwin/-/blob/master/src/placement.cpp#L198 ?) correctly , the search does not take window's stacking/last-activated rank into account in computing the overlap, but rather will traverse the screen from left to right and top to bottom and sum up the potential overlaps with all windows equally. However, there is apparently already a penalty for windows set as keep above: https://invent.kde.org/plasma/kwin/-/blob/master/src/placement.cpp#L262 No, it traverses the windows in the stacking order. https://invent.kde.org/plasma/kwin/-/blob/8f941e52508ed16f28ee23e10e4515eedb4696bb/src/placement.cpp#L248 Note that there are effectively two stacking orders - visual stacking order (workspace()->stackingOrder()) and unconstrained stacking order (workspace::unconstrained_stacking_order). The most recently raised window will be the last one in workspace::unconstrained_stacking_order. workspace()->stackingOrder() is the same as workspace::unconstrained_stacking_order but with stacking order constraints applied, e.g. a dialog should always be above its parent, etc
This bug was reported against an outdated version of KWin. We have made many changes since the. If the issue persists in newer versions can you reopen the bug report updating the version number.