Bug 450263 - In WindowHeap-based effects, use a better standard sorting algorithm instead of offering multiple options
Summary: In WindowHeap-based effects, use a better standard sorting algorithm instead ...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-window-management (show other bugs)
Version: unspecified
Platform: Neon Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2022-02-15 00:16 UTC by guimarcalsilva
Modified: 2024-02-24 02:45 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.1


Attachments
Closest is more organized but not good enough (374.78 KB, image/png)
2022-02-20 01:36 UTC, guimarcalsilva
Details
Weird window layout (442.16 KB, image/png)
2022-04-21 23:02 UTC, popov895
Details
The bottom-right screenshot is the most correct. (249.10 KB, image/jpeg)
2023-01-20 09:08 UTC, popov895
Details
Yet another example (130.02 KB, image/jpeg)
2023-01-20 14:02 UTC, popov895
Details

Note You need to log in before you can comment on or make changes to this bug.
Description guimarcalsilva 2022-02-15 00:16:34 UTC
SUMMARY

This bug is part of an ongoing effort to rethink the options available in System Settings. The end goal is to consolidate some obscure options to make Plasma feel simpler to use and improve the user experience. I was advised to make individual bug reports with my suggestions. More details with all the suggestions and talking points can be seen in this shared document: https://collaborate.kde.org/s/oEkdeYerKqaZNyC

---------

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.

SOFTWARE/OS VERSIONS
Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.24.80
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3
Kernel Version: 5.13.0-28-generic (64-bit)
Graphics Platform: Wayland
Processors: 6 × Intel® Core™ i5-9400F CPU @ 2.90GHz
Memory: 7,6 GiB of RAM
Graphics Processor: Radeon RX 570 Series
Comment 1 Nate Graham 2022-02-15 04:32:42 UTC
Yeah, this should be an easy fix, if you can come up with better text for them. Would you like to give it a try?
Comment 2 Vlad Zahorodnii 2022-02-15 08:22:22 UTC
Maybe we need to remove that option instead. I doubt that many people care about layouting algorithm.
Comment 3 Nate Graham 2022-02-15 14:51:53 UTC
Yeah I'd support that. I think it would make the most sense. Have one placement algorithm and polish it up so that it's really good and nobody feels the need to use a different one.
Comment 4 Riccardo Robecchi 2022-02-18 11:08:05 UTC
(In reply to Vlad Zahorodnii from comment #2)
> Maybe we need to remove that option instead. I doubt that many people care
> about layouting algorithm.

While I agree with Nate's sentiment, I immediately found the "natural" layout to be too chaotic for me and immediately switched to the "closest" layout which feels much more organised and pleasant to me. One issue is also that in "natural" mode the windows become too small and inconsistent.

As for the bug here, I suggest keeping "natural" and changing "closest" to "regular grid".
Comment 5 guimarcalsilva 2022-02-20 01:34:57 UTC
I agree with Vlad that not many people will care about the sorting algorithm. Actually, people will care if the default is not ideal, like in Riccardo's case, but offering more options just so the user can fix the problem himself is not the way to go. As Nate said, a good, polished default should be the goal. 

With that in mind, we need to think about which one should be the default. I tested both and I agree with Riccardo that Natural feels a bit chaotic when there are too many windows open. Closest is not perfect though, for instance, I opened a bunch of different windows, and many windows from the same app are scattered all over the grid (check attachment). The same happens with Natural, with the exception they're also visually scattered. Maybe the effect could always try to put windows from the same application next to each other.
Comment 6 guimarcalsilva 2022-02-20 01:36:37 UTC
Created attachment 146957 [details]
Closest is more organized but not good enough

Windows are not grouped together with Closest, but they are at least organized in a neat grid.
Comment 7 trmdi 2022-02-20 05:07:19 UTC
Could we use this layout?
https://masonry.desandro.com/
Comment 8 popov895 2022-04-21 23:02:48 UTC
Created attachment 148290 [details]
Weird window layout

Agreed, the layout really needs improvement.
Comment 9 popov895 2023-01-20 09:08:06 UTC
Created attachment 155448 [details]
The bottom-right screenshot is the most correct.

I just noticed that the placement algorithm literally takes into account the position of the windows, which looks odd. Please, see attached image. IMHO, it would be more correct to consider only the stack order and size of the windows.
Comment 10 popov895 2023-01-20 14:02:26 UTC
Created attachment 155453 [details]
Yet another example

There are two fullscreen Firefox windows and single Dolphin window. As you can see, by placing Dolphin in different positions, you can get different previews.
Comment 11 postix 2023-12-18 21:55:33 UTC
Maybe this proposed new algorithm [1] can replace the current both in the future.

[1] https://invent.kde.org/plasma/kwin/-/issues/189
Comment 12 fanzhuyifan 2024-02-19 11:56:07 UTC
Git commit c3cda8b62ad3825883826bdd1928c8761aeb026d by Yifan Zhu.
Committed on 19/02/2024 at 11:46.
Pushed by fanzhuyifan into branch 'master'.

effects/overview: implement new layout algorithm

Replace old "closest" and "natural" layout algorithms with new layout
algorithm. The new layout algorithm tries to
- use screen space efficiently, given diverse geometries of windows
- be aesthetically pleasing
- and minimize movement of windows from initial positions.

More concretely, find a layered layout, where each layer, or strip, is a
row or column. Ensure that different strips have similar widths, and use
binary search to find a packing with similar aspect ratio to the layout
area. Within each strip, minimize horizontal movement (for rows) or
vertical movement (for columns) of windows.

Run time is O(n) (up to log factors), where n is the number of windows.
Related: bug 477833, bug 478097, bug 477830, bug 453749

M  +6    -27   src/plugins/overview/kcm/overvieweffectkcm.ui
M  +0    -3    src/plugins/overview/overviewconfig.kcfg
M  +0    -14   src/plugins/overview/overvieweffect.cpp
M  +0    -6    src/plugins/overview/overvieweffect.h
M  +0    -1    src/plugins/overview/qml/main.qml
M  +436  -399  src/plugins/private/expolayout.cpp
M  +204  -28   src/plugins/private/expolayout.h
M  +2    -2    src/plugins/private/qml/WindowHeap.qml
M  +4    -25   src/plugins/windowview/kcm/windowvieweffectkcm.ui
M  +0    -1    src/plugins/windowview/qml/main.qml
M  +0    -3    src/plugins/windowview/windowviewconfig.kcfg
M  +0    -14   src/plugins/windowview/windowvieweffect.cpp
M  +0    -6    src/plugins/windowview/windowvieweffect.h

https://invent.kde.org/plasma/kwin/-/commit/c3cda8b62ad3825883826bdd1928c8761aeb026d