Bug 467071 - In WindowHeap-based effects, position windows near their sibling, parent, and/or child windows
Summary: In WindowHeap-based effects, position windows near their sibling, parent, and...
Status: RESOLVED DUPLICATE of bug 452447
Alias: None
Product: kwin
Classification: Plasma
Component: effects-window-management (other bugs)
Version First Reported In: 5.27.2
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL: https://invent.kde.org/plasma/kwin/-/...
Keywords: usability
Depends on:
Blocks:
 
Reported: 2023-03-08 19:18 UTC by postix
Modified: 2024-01-17 22:34 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screenshot (235.63 KB, image/png)
2023-03-08 19:18 UTC, postix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description postix 2023-03-08 19:18:53 UTC
Created attachment 157125 [details]
Screenshot

Right now windows seems to be randomly positioned in the overview, present window or grid-effect. 
In order to help the user to find the desired window more clarity is needed. 

One good way to archive this is (in my opinion) to place windows, which belong together, close to each other:
1) Place windows and their sub-windows next to each other
2) Group also windows, which belong to the same application but different instances

Additionally there could also be some other visual effect, which clearly marks that windows and subwindows are directly connected, to avoid confusion if multiple instances of an applications are running.

Please see the screenshot for the current state (5.27.2) on Wayland.
Comment 1 Nate Graham 2023-03-13 18:04:50 UTC
I think this is a good idea, yeah.
Comment 2 postix 2023-12-18 21:56:40 UTC
See also [1], a new proposed algorithm for windows placements.

[1] https://invent.kde.org/plasma/kwin/-/issues/189
Comment 3 fanzhuyifan 2023-12-18 22:26:12 UTC
From the screenshot, it seems that you are using the Natural layout (configurable in settings-window management-desktop effects-present windows-layout mode). That layout tries to place windows near their location on screen.

There is also the closest layout mode, which always creates a grid to place the windows.

The new algorithm I proposed only considers the geometries of the windows during placement -- it arranges windows by increasing height.

I like the idea of considering the logical connections between windows, but currently I don't have any good ideas on how to combine that with fitting windows of very different geometries into a fixed area.
Comment 4 Nate Graham 2024-01-17 22:34:00 UTC

*** This bug has been marked as a duplicate of bug 452447 ***