Bug 488828

JFYI I very much doubt we're going to re-add customizability here. The goal is to make something that works for everyone, not offer multiple flawed options. But we can accept suggestions for improving the current algorithm.

Let's focus on the specific ways in which the new layout is worse for you.

Better title, thanks. The main two pain points are covered in that case. 

I do feel this is a feature that can't simply be made one-for-all with no configuration options, even with a new efficient backend to power it. I imagine users of the legacy Closest layout preferred the linear rows+columns, while I prefer the "spreading" effect the Natural layout provided. Even if these behaviors are worked into the new layout in the future, there should still be a choice between them.

There seem to be two issues raised here: 

1. window sizes being too small, and 
2. windows moving from their original positions.

I will address each of these in turn below.

1. window sizes are too small

The new algorithm should be pretty efficient in using the screen space. In fact, it should be more efficient than the old algorithms than both the old algorithms in using the screen space.

Hence, if window are too small, it's because the margins are too big, or because there are too many windows open (we can't do anything about the later). For the former, it would be straight forward to decrease the size of the margins if that indeed is the issue.

Could you please upload a screenshot showing the problem you preserve, so we could take a look? Also, letting us know the resolution of the screen would be helpful.

2. windows moving from their original positions.

IMO if we operate with a tractable (i.e., computationally efficient) algorithm, there is a fundamental trade-off between making efficient/aesthetic use of screen space, and minimizing movement. (if there is an efficient algorithm that can accomplish both, I would love to learn about it) The old natural algorithm often made horrible use of screen space, and people complained about that as well (e.g., BUG 477833, BUG 477833, and attachments in BUG 450263).

Hence, at some level, we have to make a judgement call between minimizing movement, and making efficient/aesthetic use of screen space. Users should have little need for this algorithm when all their windows already don't overlap. Thus, we decided to some what prioritize making efficient/aesthetic use of screen space, given that the algorithm is most useful when a lot of windows overlap, and in this case minimizing window movement doesn't really matter.

In addition, the implemented algorithm has components to minimize movement, contrary to what I said in that comment you mentioned. In the merged version, (assuming a landscape display), the windows in each row are sorted by their original horizontal positions. Hence, horizontal movement is minimized.

If you could upload a screencast demonstrating the problem you see I would be happy to take a look.

Comment #3 asks for more information, we can revisit this if that occurs. 
Though this bug report is mostly a personal preference and it isn't possible to match everyone's opinion.

Created attachment 171079 [details]
6.0.5-Overview-effect

Created attachment 171080 [details]
6.1.0-Overview-effect

Sorry for the delay, this was a fairly useless report without visuals, I apologize. 
Had to focus on several other things before having time to come back and record the behavior.

Here are videos of my screens using Natural layout, my common interaction with Overview on the right screen (open browser tabs by topic, divvy them to other desktops), and the left screen with static unmoving windows. This in in Wayland but the X11 behavior is identical. 

Then the same routine in 6.1 with the new algorithm.

--

The leftmost portrait screen illustrates both the position and scale issue:

These windows are static and won't ever change, they're set in place at launch by kwin window rules and pinned across virtual desktops (but not tiled using custom or quick tiling). The old Natural layout barely moved them due to the presence of no additional windows in the screen, but now they do move quite a bit and it's jarring and distracting.

The windows now jump across others due to wanting to assume a more gridlike position, when they should stay in place movement-wise and ease into the transition if there are no other windows, same as before. The zoom/scale effect is also stronger than before, which is fine on the rightmost screen but could potentially be turned down overall.

*Could it be possible to generate a special conditional layout when all current windows are already visible/tiled per screen, to prevent unnecessary movement and zoom?*

--

The right screen mostly indicates the position issue due to my most common window dimensions:

As I'm coming to learn, the number of windows, their dimensions, and positions dynamically calculate a layout on each invocation, and while windows try to hold positions, they can travel far and cross other windows if they need to reach a proper-sized slot. Correct me if i'm understanding this wrong though.

Due to my amount of half-snapped windows, the layout ends up resembling the former "Closest" grid most of the time, making the windows travel farther than they would have on Natural in order to preserve their scale, and this makes them across other windows. I never used Closest in practice, but this seems to be what it resembles with my usage.

This is what I'm attempting to convey, the new layout tends to lean to more of a rigid grid due to my most common window dimensions, when I prefer instead to have them laid out in a more scattered/radial grid and prioritize keeping their position over scaling. 

Now knowing the new system also takes into effect window position, (and now that I have kdesrc-build fully set up for testing) I want to try adjusting values to see if I can affect the layout to more prioritize positions and see if it improves the experience for me.

Some notes after modifying values and testing with kdesrc-build: 

-- Sizing/Padding

Adjusting m_relativeMargin variables in expolayout.h works to help window scaling. Less margins = larger window previews. The default of 0.07 on all sides are far too large, even 0.02 has too much space. 
I think a value of 0.01 looks great, while I'm sure many users will think I am wrong and prefer the default or even larger gaps. User customization would shine here. 

-- Positioning

The other variables defined in expolayout.h don't modify the basic row/column behavior of the grid layout. Had hoped there would be a value to determine the clinginess of a window to it's nearest cell, but it is not possible to achieve anything like a radial layout using this new code, so that wouldn't make any difference. 

Quoting the reference paper: https://invent.kde.org/plasma/kwin/-/issues/189
In LayoutClosest the algorithm creates a rectangular grid of slots, and assign windows to those slots.
In LayoutNatural, the algorithm incrementally adjusts the windows, scaling or moving them, based on nearby available space and overlaps.

The current system is akin to LayoutClosest, with dynamic column/rows generated, where windows will travel over others to reach their target slot. Wondering again if it could be possible to generate conditional layouts based on position/overlap, which would of course bring it closer to the previous Natural behavior. 

--

I've patched my system Kwin package to revert this entire change in the meantime, while I test in a local profile. 
A non-technical question that I'm genuinely curious about, enough to bother asking: 

What is the rationale behind deciding not to offer any user customization with this radically changed layout?

The bullet points I've read in the general design docs concern overwhelming users with options and potential misconfiguration, those simply don't make sense in this context. 
I would love to contribute and add small options to the KCM module to improve this new layout (like a slider or integer for Padding size mapped to m_relativeMargin), but I don't want to waste time if they aren't even going to be considered by design.

Let's make this just about the spatial positioning, which is a thing the new layout algorithm changed. The sizing is largely determined by the margins and view area of the effect itself. Let's track with in Bug 490914.

Thanks for the bookkeeping, I've followed that ticket as well. Hate to be a broken record, but I'm going to continue to strongly assert that a choice of multiple layouts is the way to go here, and that will be the focus of this ticket. 

Can't suggest any further improvements to the new layout. As a replacement for the mostly-broken former "Closest" layout, this new one works as written on the tin aside from the spacing/padding in this initial take. There is no current way to hack or force the new layout algorithm to resemble Natural. It's a fixed Closest for lack of better label. 

Those grid-like layouts follow Windows/GNOME behavior, and that's fine and dandy for users that prefer that way. 

The Natural Layout follows the behavior of Mac OS Mission Control, that's the difference. It's binary, day and night, 0 and 1. 

Natural worked. The behavior reported in >>BUG 477833 is very close if not identical to how Mac OS handles window management, a few bugs could have been addressed without simply scrapping the whole layout. 

One size can't fit all, especially when Plasma has offered two options for ages, since well before my time. Anecdotal but one of the main reasons I started using Plasma daily was due to annoyance with Windows's grid-like Task View layout. Kwin had the attractive Natural layout with Present Windows and Desktop Grid, and it fell into my workflow right away. Overview was icing on the cake when it was released and smoothed out (it resembles Mac OS even closer, and better fits my job workflow). 

There should be two distinct layout options with user choice between the two. Can't say it any more clearly. 

----

From >>BUG 450263, the report that drove this change in the first place. 

> In the effect options, there's an option to switch the layout between Natural/Closest modes. 
> There's no explanation of what those options actually mean and the names are not self-explanatory. 
> Maybe an information icon (i), like is present in some other KCMs could be added to explain what they do.

Yeah, that follows! While intrepid users can just switch back and forth between the two to get an understanding of what the difference is, Plasma places an emphasis on using better language/human interface so that's the smart way to handle this. "Natural" or "Scatter" can describe the Mac-like design, and "Grid-like" can describe the new currently-unnamed layout, with a radio button toggle between the two, and tooltips or visuals on the difference. 

I've brainstormed ways to integrate both layouts back into the system, and with any kind of positive response, I'll start tinkering and trying to get that working. Really want to help improve this instead of just griping :)

After spending this fall trying out different Kwin debugging setups and environments, and taking time up and close with the Overview and Grid: I still cannot get behind the new layout. 

I set up an issue page earlier with a branch that integrates both layouts into Plasma 6.2+ and proposes a configuration UI enhancement: https://invent.kde.org/plasma/kwin/-/issues/239. 

I'm more surprised than anything that there's no mention from anyone on public forums regarding the removal, even after 5 months. 
It seems that nobody else used the Present Windows + Desktop Grid effects with Natural layout for years like I had, or that nobody valued the choice between the layouts.

Everything is ready apart from the (frankly unnecessary at this time) UI enhancement, so I won't update this bug report from here until there's a definite yes or no on whether the feature will be re-added based on the branch I put together. 
Really hope another user does notice the feature is missing and can chime in to back me up though.

Setting to RESOLVED/LATER, I intend to maintain this feature indefinitely. 

In discussion on Matrix, it's been made clear that: 
- This feature will not return unless ported to a Kwin extension.
- Overview is not intended to replace the Present Windows + Desktop Grid workflow.
- Those advanced features can just go into extensions.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6983

Re-opening this, it's so useful that I can't just let it fade out. Someone reached out on Reddit letting me know they miss this feature too.

Hi, after upgrading Debian last month, I realized something was "off" to me about the new Overview in KDE 6. It's the window placement, like you said, the Windows travel farther than they used to, since I guess they're sorted by height now? 

Most of the changes in 6.x were good, but this was a step back, especially since the option to choose the layout is gone. Is there any chance we could see the old layouts as an addon?

Hey, thanks for speaking up! Yes, the new Overview is honestly good, aside from the lack of options like this.

> the Windows travel farther than they used to, since I guess they're sorted by height now?
This is true, one of my biggest faults with the new layout. It's overanimated when you have many windows pinned to a static secondary screen, and honestly borders on sensory overload from an accessibility standpoint, all the stationary windows playing shuffle unnecessarily, when previously they would just ease out slightly. 

> Is there any chance we could see the old layouts as an addon?

I'm actually working quite hard on an addon fork of Overview that restores the Natural layout and other options: https://invent.kde.org/breakingspell/kwin/-/work_items/1. My goal is to make this as easy to install as possible across multiple distros, but unfortuantely since it must be compiled, it's not as easy as just hitting "Get new effects" in System Settings. I'll be posting all updates on that link. 

In the meantime, it's currently easier to patch and recompile your distro's kwin package. Debian has an easy and well-documented helper (quilt) that this diff should drop right into: https://invent.kde.org/plasma/kwin/-/merge_requests/6824.diff. Once patched, you get a .deb package that replaces your regular kwin. 

Let me know if you need help with this, there's also a thread on discuss.kde where we talk about patching OpenSUSE, which uses the same tool: https://discuss.kde.org/t/window-sorting-in-overview/40468

Got it loaded without much trouble using quilt, I found your kwin-x11 version and applied that patch. Thanks for the pointers and keeping it maintained! Really looking forward to your full Overview addon. Interesting that we have to compile stuff for addons in 6.x, but I had to do the same with the Better Blur addon.

To be honest, the window sizes with the Natural layout do look worse when compared to the new one, but the positions keep for nearby windows like it should. It's worth the tradeoff, and it's the same effect i'm used to seeing anyway. Plus I can just switch between them to compare.