| Summary: | Taskbar always groups similar windows, even when it's not full | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Mircea Kitsune <sonichedgehog_hyperblast00> |
| Component: | widget-taskbar | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | dweeble01103, hein, sonichedgehog_hyperblast00 |
| Priority: | NOR | ||
| Version: | 4.11.2 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.11.3 | |
| Sentry Crash Report: | |||
| Attachments: | showing grouping even though space available (and tray settings) | ||
|
Description
Mircea Kitsune
2013-11-14 13:16:03 UTC
To be blunt: The calculation of "we're full now" threshold was simply broken as far as 4.11.2 due to a bunch of accidental wrong assumptions and a logic error - it was fixed for 4.11.3, and should now behave correctly. Please re-test with that release, and reopen if you still have problems. I can confirm it does not work properly in 11.3 (at least for me), see attached pic Created attachment 83560 [details]
showing grouping even though space available (and tray settings)
Roughly, the Task Manager is considered full if it needs to start shrinking tasks to fit them. Going by your screenshots I'd guess the calculated threshold is 6 (the preferred maximum width derives partly from the font settings, and in the shot there's probably enough room for three full-width tasks per row). The problems in <4.11.2 were an off by one, a possible calculation error when "Force Rows" was enabled that resulted in too-low thresholds, and a possible race condition where the threshold wasn't invalidated after an applet size change. I'm quite confident those bugs are addressed, i.e. what we're left with is a policy decision. I understand that in your screenshot it feels to you like there is room because there's this attractive-looking gap there, but this is somewhat of an edge case (most people don't use multiple rows) and basically orthogonal to what size to use for the "how many tasks fit" decision. Currently the preferred maximum width is used; certainly it could also be the preferred minimum width or any point in the range instead, but the max width is very similar to what the old applet worked with as well. You could add a special-case behavior like "if we've overflowed into multiple rows already, always use a multiple of the number of tasks we're currently fitting into the first row", but you'd have to put a cap on that for situations with very many tasks, and then further special-case for "Force row settings" (you can have multiple rows even with only two tasks, then). The current algorithm is very KISS. Thanks for the info, I'll wait for my distribution to update to KDE 4.11.3. |