It seems to me that the layout algorithm tries to mimic the original positions of the windows, which can easily lead to small previews, while half of the screen is empty. Filling the entire screen should have much higher priority. I'm using the "Natural" layout mode, but the other two also suffer from this problem. Reproducible: Always
> It seems to me that the layout algorithm tries to mimic the original positions No, doesn't. Can you please attach a screenshot of the condition you concern (you can blur the window contents)
Created attachment 94167 [details] present layout.png (In reply to Thomas Lübking from comment #1) > > It seems to me that the layout algorithm tries to mimic the original positions > > No, doesn't. Yes, it does. If I move the windows around, the layout changes. > > Can you please attach a screenshot of the condition you concern (you can > blur the window contents) Attached an example. There are 4 big windows on top of each other that are almost fullscreen, and 3 small ones near the bottom left corner. The layout pushes everything into the bottom left corner.
I see what you mean, but that is the behavior of the "natural" layout and that layout *only* It tries to preserve the ratios of window sizes (ie. if a window is twice as big in "reality" it's twice as big in the overview) and their relative position on screen. This has of course some drawbacks, but is just the idea of that layout. If you don't want that, use the flexible or regular grid layouts. Personally, I prefer the regular grid since tiles are simpler to handle for the human brain, ie. are "faster". The flexible grid makes (slightly) better use of screen estate, though. If you can expose similar problems (wit obvious solutions) on those two layouts (notice that the regular grid needs to fill an even grid, ie. all slots have the same size), please do so. Otherwise this is no bug, but indeed the strategy of the *very* selected algorithm by definition.
Created attachment 95086 [details] present layout regular grid.png As the attached screenshot shows, regular grid is also quite suboptimal. It also has a missing feature compared to natural: windows created while the effect is running don't show up.
(In reply to miklos from comment #4) > It also has a missing feature compared to natural: windows created while the > effect is running don't show up. Sorry, that's nonsense. It's the very same code, just the position calculation differs. If a window doesn't show up in one configuration, it won't show up in the others either. How did you create the constellation in the screenshot? HUGE Panels on top and right side?
Created attachment 95863 [details] present windows terminals.png Meanwhile I upgraded my system, and I got KDE5. I can no longer reproduce the above problem with grid layouts. I also found out what caused the weird layouts on the screenshots. Steam creates popup dialogs for group events (always on the current desktop), that are invisible, until I specifically alt-tab to them (so they tend to amass). These don't show up in present windows, but they are accounted for. Now I disabled focus stealing prevention to see if they keep being created as invisible. However, I can still force the natural layout to produce weird results with only 3 terminal windows. The screenshot was created with 3 terminals in the top left corner, one of them maximized vertically, and one of the small ones moved down a bit. If I move at least one of them out of that corner, the present layout gets much better.
(In reply to miklos from comment #6) > Steam creates popup dialogs for group events, that are invisible > ... > These don't show up in present windows, but they are accounted for. *cough* https://git.reviewboard.kde.org/r/122435/ *cough cough* ;-) > However, I can still force the natural layout to produce weird results Quite frankly, I personally don't deem the "natural" layout a very reasonable approach - the idea of present window (aka "exposé"...) is to provide a general overview on your windows. Trying to reproduce the desktop mess as it is seems rather counterproductive. Closing "worksforme" If you'd like to open a bug that says "If clients map iconified, there's no thumbnail in the compositor and an empty space in some effects" ... I'm not holding you back :-P