SUMMARY Windows are now being cascaded after https://bugs.kde.org/show_bug.cgi?id=58063 was implemented for 5.27. This feature can currently be a bit unexpected in some specific scenarios, and I'd like to suggest changing it slightly to take care of this. As an example scenario, consider this: a user has opened a Dolphin window with a relatively small window size. They have opened a maximized terminal emulator above this Dolphin window. They then open System Settings, and its window is larger than the Dolphin window. The System Settings window is then being cascaded, despite Dolphin being behind the (maximized) terminal emulator. My proposal would be: do not consider windows that are already being covered by other existing windows when deciding whether a new window is being cascaded or not. In the example scenario above, the System Settings window is being cascaded, even though the Dolphin window that triggers this behavior is not currently visible to begin with. STEPS TO REPRODUCE 1. Set window placement to "Centered" 2. Open a small window 3. Open or move a maximized window in front/on top 4. Open a window that would cover the previously opened small window OBSERVED RESULT The window opened last is being cascaded, therefore being off center. EXPECTED RESULT The window is not being cascaded, because cascading it does not prevent the small window being covered in this case, as it had already been covered before. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.27.0 ADDITIONAL INFORMATION This may also be of relevance: as of this change, forcing a centered window placement via "Window Rules" -> "Initial Placement" can also cascade the window. This may be unwanted behavior, assuming the user actually wants to force the window to be in a centered position.
Makes sense to me.
I'd like to second the issue raised in the original post's additional information section. I think I'm in the minority, but I preferred the original behavior where new windows just stacked on top of each other and did not cascade. It would be nice to have a switch to turn the cascading off, or at least be able to override it with a rule.
(In reply to mccambria from comment #2) > I'd like to second the issue raised in the original post's additional > information section. I think I'm in the minority, but I preferred the > original behavior where new windows just stacked on top of each other and > did not cascade. It would be nice to have a switch to turn the cascading > off, or at least be able to override it with a rule. To get custom window behavior we have scripting functionality in KWin, here is one that does what you want: https://www.reddit.com/r/kde/comments/117oywo/comment/j9d3ewk/?context=3 In any event this is a different feature request; if the above solution is not satisfactory could you file a separate report for that, and explain what the use case is and why a KWin script is not enough?
(In reply to Natalie Clarius from comment #3) > (In reply to mccambria from comment #2) > > I'd like to second the issue raised in the original post's additional > > information section. I think I'm in the minority, but I preferred the > > original behavior where new windows just stacked on top of each other and > > did not cascade. It would be nice to have a switch to turn the cascading > > off, or at least be able to override it with a rule. > > To get custom window behavior we have scripting functionality in KWin, here > is one that does what you want: > https://www.reddit.com/r/kde/comments/117oywo/comment/j9d3ewk/?context=3 > > In any event this is a different feature request; if the above solution is > not satisfactory could you file a separate report for that, and explain what > the use case is and why a KWin script is not enough? That worked perfectly! Thank you for pointing out that option.
Cool. Let's close this and see if we get more complaints.
(In reply to Nate Graham from comment #5) > Cool. Let's close this and see if we get more complaints. Hey Nate, did you close this ticket accidentally? mccambria's issue has been resolved my Natalie's help, but that's not what this ticket was about in the first place :)
Oh right. Yeah the initial issue is valid.
Re. the original issue, I think the issue is valid but haven't been able to think of a solution that wouldn't be O(n^2) which Vlad said should better be avoided.
Could you not get a sorted list of windows, trim any elements behind the topmost maximized window and then run your overlap checks on the remaining windows? This would not properly handle all cases, but I think it handles many of the common cases. Maybe. I'll need to think about this more.
(In reply to Ennea from comment #9) > Could you not get a sorted list of windows, trim any elements behind the > topmost maximized window and then run your overlap checks on the remaining > windows? This would not properly handle all cases, but I think it handles > many of the common cases. Maybe. I'll need to think about this more. Yeah, something like that might work well enough for the most prominent cases. The relevant code is at https://invent.kde.org/plasma/kwin/-/blob/master/src/placement.cpp#L593. Feel free to give it a shot!
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3761
Git commit 39cea49a8fac55beae6d3bff51814b81ec34df87 by Vlad Zahorodnii, on behalf of Natalie Clarius. Committed on 08/03/2023 at 19:04. Pushed by vladz into branch 'master'. placement: don't cascade for the sake of windows that are already covered When checking for overlap with other windows when placing a new window and cascading to avoid complete overlap, ignore those windows that are already covered by other windows further on the top anyway. The computation of the covered area is not entirely accurate as it uses the bounding rect rather than the combined rects of the windows, but okay enough for our use case imo. M +16 -4 src/placement.cpp https://invent.kde.org/plasma/kwin/commit/39cea49a8fac55beae6d3bff51814b81ec34df87