Task manager window grouping failures and KWin window-action slowness

Stephen Dowdy sdowdy at ucar.edu
Sat Aug 5 18:23:38 BST 2017


I have LOTS of windows, and while task manager window grouping in KDE4
started off pretty bad early on, it got better for me.

In Debian Jessie, i would have issues running 3 different firefox
profiles with differing Class Instance names, where it would still
*usually* correctly separately group them, but sometimes draw the
incorrect icon for them. 

Now, in Debian Stretch, the icon managers are *TERRIBLE* at grouping my
firefox windows.

I have *hundreds* of firefox windows, and i'm lucky if task manager
manages to make 1 or 2 groups of a few tens or dozens, and then ALL of
the rest become individual task manager icons.

(race condition?)

I prefer using Icon-only Task Manager with "Show Launcher when not
running"  (though, interestingly, in Icon-only mode, there's not "Group
Windows" setting button)

I have tried switching "Alternatives" hoping that doing so would issue a
"regroup" operation, but it seems that the grouping algorithm is done
one-time at window creation in some common code?

Is there any way to FORCE the code to re-evaluate grouping?  Or, is this
bug fixed in subsequent Plasma or KDE Frameworks (or whatever component)
releases?

Additionally, i like to set window-action for double-click title bar to
"lower".  with many windows, it can sometimes take 30 seconds for the
action to complete.  it sits there doing nothing, and i don't know for
sure if it's that i keep hammering at it, or i move the mouse and click
in different windows, then hammer on it some more, but it eventually
will do a lower. (it's not ALWAYS that slow).  Sounds to me like some
code branch goes off to evaluate something and gets all caught up in
some operations that don't scale very well to hundreds/thousands of
windows).

These are regressions from behaviors that USED to be fine (mostly in
KDE3 where on a much less substantial machine than what i have now, i
never had any issues of unresponsiveness.  yes, Firefox has had a role
in creating unresponsiveness), but in jumping from Debian Jessie to
Stretch, i'm finding a lot of little issues in Plasma5 that i do NOT
want to throw at my users yet, and am being forced to evaluate
alternative DEs.  (SDDM is god awful slow and the cursor can take tens
of seconds to show up sometimes, KDE session initialization takes much
longer than KDE4, race conditions can cause context bubble windows to
get permanently stuck on the plasma-desktop, etc.)


[VersionInfo]
Qt: 5.7.1
KDE Frameworks: 5.28.0
plasmashell: 5.8.6


thanks,

--stephen





More information about the kde mailing list