| Summary: | In WindowHeap-based effects, use a better standard sorting algorithm instead of offering multiple options | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | guimarcalsilva |
| Component: | effects-window-management | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | nate, popov895, postix, sephiroth_pk, trmdi |
| Priority: | NOR | Keywords: | usability |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/c3cda8b62ad3825883826bdd1928c8761aeb026d | Version Fixed In: | 6.1 |
| Sentry Crash Report: | |||
| Attachments: |
Closest is more organized but not good enough
Weird window layout The bottom-right screenshot is the most correct. Yet another example |
||
|
Description
guimarcalsilva
2022-02-15 00:16:34 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? Maybe we need to remove that option instead. I doubt that many people care about layouting algorithm. 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. (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". 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. 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.
Could we use this layout? https://masonry.desandro.com/ Created attachment 148290 [details]
Weird window layout
Agreed, the layout really needs improvement.
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.
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.
Maybe this proposed new algorithm [1] can replace the current both in the future. [1] https://invent.kde.org/plasma/kwin/-/issues/189 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 |