Choosing "Grouping by product name" and "Only when taskbar is full" causes groups to be created even with only two (same) tasks running, on a panel with a height of about 36 pixels. This started happening in KDE 4.11, the same configuration used to work fine before. Increasing the height restores the correct behaviour at some point but I would prefer that I didn't have to do that. Reproducible: Always
Created attachment 82450 [details] screenshot explaining the problem
Do you have "Force Rows" enabled in the config dialog?
(In reply to comment #2) > Do you have "Force Rows" enabled in the config dialog? Yes I have, and disabling it doesn't make a difference. Please, take a look at the attached screenshot as it includes my configuration.
Sorry, and thanks (I didn't expect the shot to contain the config dialog, and the problem is definitely unrelated to height, that's why I didn't check it).
I'm sorry if I didn't make my self clear on my original description. If I increase the panel's height (let's say, 45 pixels and above) then groups start working as expected, they are only formed when the taskbar is actually full. That made me think that low height is the reason this happens.
No, your description was very clear, and I have no reason to doubt those are the symptoms you are observing, the code-internal situation is simply a bit more complicated :). Thank you for your report at any rate, I've audited the related code once more, and while it works fine in most cases, there are some fixes to make. I'll work on that shortly; unfortunately with 4.11.2 being tagged tomorrow, that will put those fixes most likely into 4.11.3. Unfortunate timing.
Git commit dc234dba2f381e5b2bbd003f0e0a39e2428c10ad by Eike Hein. Committed on 27/09/2013 at 09:27. Pushed by hein into branch 'KDE/4.11'. Fix calculation for "group only when full". * Fixes potentially miscalculating the threshold with "Force Rows" enabled. * Fixes potentially being left with a stale threshold in the group manager due to a race condition between reacting to an applet geometry change and recalculating the threshold. * The calculated threshold was generally off by one thanks to misinterpreting the libtaskmanager API naming. M +2 -2 plasma/desktop/applets/tasks/package/contents/code/layout.js M +1 -1 plasma/desktop/applets/tasks/package/contents/ui/main.qml M +5 -8 plasma/desktop/applets/tasks/tasks.cpp M +1 -2 plasma/desktop/applets/tasks/tasks.h http://commits.kde.org/kde-workspace/dc234dba2f381e5b2bbd003f0e0a39e2428c10ad
Good news: 4.11.2 is behind schedule and wasn't tagged yet, so these fixes will roll out sooner than expected.
Things have improved a lot in 4.11.2 but I feel this isn't completely fixed. I can open 3 instances of a task without a group to be formed, but then on the fourth a group is created when 6 or more could fit without the taskbar to be considered full.
"Full" occurs when there are more tasks than fit into the width (or height, with vertical orientation) of the applet at their preferred maximum width (or height) multiplied by the number of rows (or columns) there is space for. In other words, with opportunistic grouping enabled, in a situation where there are enough tasks for any of the tasks to be shrunk below their preferred max size to make them fit, an attempt at grouping is made instead. I can no longer reproduce any issues with this; if you see behavior that differs from what I outlined, a video would be helpful.
Created attachment 82626 [details] video portraying the problem
As I'm not sure I understand your description, I'm uploading the video anyway. Thanks for your work and attention on this.
Thank you, that video helped - there's indeed a stupid bug remaining. Do you have time to contact me on Freenode IRC, nickname "Sho_", so I can run a fix by you?
With 33f1a1ef the launcher items are now taken into account when calculating the grouping threshold - I mistakenly assumed the lib did this on its own. This should help.
Ah crud - we just found out this actually missed the 4.11.2 tag after all :(.