Stephen Dowdy posted on Sat, 05 Aug 2017 11:23:38 -0600 as excerpted:
> 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?)
Sounds like it.
Right here at the top I'll mention that my usage is much different than
yours so the degree of practical help I can provide is very limited, but
I do run live-git "kde family", from frameworks, thru plasma and apps,
and follow plasma's (that's the whole desktop including kwin, plasma
system settings, etc, not just the shell) development via the plasma-devel
list which gets all the pre-master-merge discussion, and am thus at least
somewhat aware of developments that don't directly affect my own use, but
will affect yours. It's on that basis that I'm replying.
I neither group windows nor use a taskbar at all, here, preferring window
management alternatives such as the alt-tab switcher, multiple desktops
with switching via desktop scroll or cube, the window list menu which I
have configured to popup with a "middle" button click, etc. It also
helps that I have a /huge/ desktop, a 65"/165cm 4K TV (3840x2160) as my
primary monitor, with window rules set to default most windows to
1280x1080, so I can do a 6-off grid of three windows wide by two high, so
I don't need to Z-axis stack them so deeply, particularly when using
multiple desktops as well. (I also have a secondary 48"/122cm "full-HD"
TV (1920x1080), on which I can and often do have a full-screen youtube or
the like session playing, the idea being it can be full-screen on that
monitor and still not encroach on my 3x2-window main work display area.)
Between that and the fact that I'm an old-timer whose computer workflow
consists of opening windows to work on, working on them, then closing
them, closing and restarting windows/apps as needed rather than leaving
them hanging around unused for days at a time, I don't usually get the
number of windows you're quoting and thus don't tend to end up /needing/
to manage hundreds of windows at a time.
Tho I will often open up to perhaps 50 firefox windows or so while
catching up on news, along with a news/feed/mail reader (which close to
the tray and I seldom have more than one open at a time), maybe a reply
window for messages such as this, and perhaps 2-3 konsole windows if I'm
updating (gentoo so that means building from sources) the system at the
same time.
But still almost never more than 100 windows, and most of the time under
50, quite a way from your several hundred. But it works for me, and if
yours works for you... =:^)
> 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?
I'd expect so... people don't tend to like windows showing up in one
group, then moving to a different one just because the name of the window
changed or something similar, after all.
> 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?
One "hackish/manual" technique I've had some success with, is using the
command line at first, then scripting if whatever bug is forcing it
continues to happen frequently enough, to quit (kquitapp or killall, or
using htop, ksysguard, etc) and restart whatever plasma component,
whether that be kwin (kwin-x11), plasmashell (the desktop activities and
panels themselves), krunner (the run dialog), xembedsniproxy (the
"legacy" tray app proxy), etc. Just don't try to quit and restart
ksmserver, startx, xinit, startkde, etc, or you'll shutdown the entire
session!
In fact, I've one entire hotkey launcher menu dedicated to resetting/
restarting various components, both kde/plasma related as above, and
otherwise (resetting mouse accel (xset m(ouse)), keyboard repeat rate
(xset r(epeat)), reloading my now kde-independent due to kde breaking
what was working just fine with no work-alike alternative on major
upgrades several times hotkey app (sxhkd for the hotkeys and a hand-
rolled konsole/bash-script combo for hotkey menus) after editing its
config, etc).
Since I don't use window grouping I'm not sure which component handles
that, but I'd guess restarting either kwin or plasmashell (and thus
whatever taskbar-ish you're using), depending on what handles the
grouping, would do it. As I said I have both of them listed in my resets
hotkey menu, here.
> 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).
As mentioned I run live-git kde-(frameworks/plasma/apps) here, and follow
plasma development. They've been working on the grouping code fairly
recently, adjusting the matching for firefox and chrome/chromium windows
for sure. IIRC they were using regex (I believe it was regex, not shell-
wildcards, but please verify before depending on that), I believe via qt's
regex services, for matching the groups, and tweaked the regexes to
account for recent changes, etc.
I've no idea how to get what current live-git frameworks considers its
version number (update, frameworks 5.37.0 according to konsole's about
konsole, libraries tab), but for reference, plasmashell --version reports
5.10.90 (which I believe is pre-release for 5.11), here, compared to your
5.8.6, below.
Google says plasma 5.8.6 was released on February 21, 2017, so it's not
that old, but the 5.8 series is of course an LTS, with 5.8.0 released on
Oct 4, 2016, again according to google. Tho of course they'd have
branched what was to be the 5.8 LTS some time before that.
So you do very likely have the window-grouping code changes still ahead,
unless they backported them before the 5.8.6 release in February.
Meanwhile, I can see the lower possibly taking awhile on hundreds of
windows, particularly if they haven't optimized window trees for fast
access with hundreds or thousands of windows in mind, **ESPECIALLY** if
it means they have to go searching the perhaps unordered window list
multiple times to match all the grouped windows so they don't lose track
of Z-stack order for the group, with some still set as somewhere other
than bottom of the Z-stack.
Meanwhile, if I may ask, how many core and hyperthread is your CPU? What
does CPU usage do during this 30 seconds? Does it spike on one core/
thread, all of them, or no significant increase? With hundreds to
thousands of windows, particularly if it's unoptimized as my suggestion
above, if the code isn't multi-threaded, I can certainly see it taking
some time. Multi-threaded would help with that, but of course
dramatically increase the possibility of race conditions at least in
relatively early code, until the bugs are worked out. And with few
people likely having that many windows (I've seen people report hundreds
of firefox /tabs/ before, but not hundreds of windows), it could be
awhile before all the race conditions are reported, traced, and fixed.
And memory. How much and do you run swap, and how far into swap do you
go, if you do? Of course if some of these windows are swapped out and
have to be swapped in to manage (not that they do, but if...)...
FWIW, 6-core AMD bulldozer-1 (fx6100) here, overclocked to 3.7 or 4.07
GHz (3.7 previously reported, 4.07 reported on kernel 4.13-rc3, don't
know yet if it's a fix or regression in 4.13, but IIRC the slightly above
4 better agrees with the bios overclocking page so it /might/ be a fix,
tho I've not rebooted to the BIOS since discovering it to verify what it
says there so that's from memory).
16 GiB RAM, no swap and swap disabled in the kernel config too.
Typically I use a quarter to a half of that, 4-8 GiB, including cache,
unless I'm updating (I build in tmpfs so usage goes up then, tho rarely
above 12-14 GiB), tho I run multiple partitions and mount some of them
only when needed, unmounting when done, so my cache usage is reasonably
conservative, and as I said, I run apps on demand and shut them down when
done, as well, so app usage is relatively conservative as well.
I'd expect your usage to be rather higher with so many windows open,
likely into swap if you're only running 4-8 GiB of RAM.
> 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.)
I've not noticed that, but I've been running the main system on SSD for I
think about four years now, and recently upgraded the larger media and
backups partitions to ssd as well, so am all-ssd now.
What I *have* noticed is that if I login and run startx (which starts a
kde/plasma session as my user, I don't use a *DM graphical login) too
quickly, the Radeon graphics will have apparently not fully initialized,
and plasma comes up with effects disabled. Then I have to enable them
and restart superkaramba (which is kde4-based and EOL with no proper
frameworks5 alternative, unfortunately) in ordered to get transparency
for its window, since it checks for support at init.
Similarly, even if effects come up fine, often xembedsniproxy (the
"legacy" systray app proxy) dies and I have to restart it, to get the
full set of tray icons including the gtk2-based pan and claws tray icons
for may news/feeds/mail apps.
But kde/plasma starts up within a few seconds, "fast enough" it doesn't
seem too long for me. Tho admittedly it did take a bit back when I was
still on spinning rust, but that has been a few years now, so I've no
idea what it'd be like now.
> [VersionInfo]
> Qt: 5.7.1 KDE Frameworks: 5.28.0 plasmashell: 5.8.6
Also qt 5.7.1 here. 5.8 had major issues with kde and has been skipped
by most distros, and the 5.9 LTS, while initially released the end of May
(2017), is still being integrated by most distros, including gentoo,
where it's apparently still only available in the gentoo/qt overlay, not
in the main tree, even masked for testing, yet.
As I said above, live-git kde frameworks/plasma/apps here, with
plasmashell reporting 5.10.90, pre-release for the 5.11 series, and I'm
not sure how to check what frameworks report themselves as, other than as
a git commit.
Actually... I just found that konsole's about konsole dialog lists
frameworks version on the libraries tab, which says... Frameworks 5.37.0.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
