KDE's rough edges... what are your experiences?

[Duncan]

Michael posted on Sun, 27 Oct 2013 07:54:09 +0100 as excerpted:

> Hi peops,
> 
> I somewhat force myself to use KDE (once again), even though I am very
> likely to get annoyed rather fast when it comes to the KDE-specific kind
> of issues. Issues, I have never seen with any other project to that
> extent. And I ask myself, if others are annoyed too there or am I just a
> whiny little bitch and no one else really bothers there?

There are certainly issues with most desktop environments.  But I've yet 
to find one I like in its default state and I doubt I ever will, which by 
definition means I tend to be a *HEAVY* customizer, and kde does tend to 
support a higher level of customization than most desktops.

But that doesn't by any means mean I don't have my own frustrating 
issues...

> To describe the kind of issues I am referring to, some examples:

> 1.) KSysGuard: I just closed a program via its own menu (file ->
> close), wondered why even after several minutes (and even now, half an
> hour later) KSysGuard still showed that process, so I did look with "ps"
> and to my surprise, the process is *not* there anymore, but KSysGuard
> shows it nevertheless in the "process table".
> https://bugs.kde.org/show_bug.cgi?id=261255

ksysguard is an interesting one.  There's a couple points I can make 
about it, with the second leading into a rather wider discussion, and 
finally a third point/hunch that might be worth investigating, just in 
case.

First point, most directly apropos to that bug, while I'd /think/ it 
would be obvious enough to note as it was my immediate first question 
upon reading the above, you didn't above and nobody seems to have noted 
it specifically in any of the bug comments either...

What do you have the sheet/tab properties update interval set for?  If 
it's set to zero, it's not going to update and of course the information 
will ultimately go stale.  Similarly if the interval is maxed out... here 
the max it will let me enter is 1000 seconds, aka 16 minutes 40 seconds.  
You do mention half an hour so it should have updated in that time, but 
perhaps only once.

Given the importance of the question I can't see why nobody on that bug 
(or you above) specifically mentions that they do NOT have the update 
interval set to zero and what they DO have it set at.  Similarly, nobody 
mentions whether OTHER processes are updating or whether it's essentially 
a static display of a one-shot sample, which would explain...  That may 
or may not be the issue, but if it isn't, how can such basic information 
be overlooked in the bug report or here?  That implies people simply 
haven't checked, which means it well COULD be the issue!

The second point is a MUCH more general point, applying both to ksysguard 
and to kde, specifically kde4, in general.

ksysguard was in fact one of my early kde4 pain points.  Back in the late 
kde3 era, I had the ksysguard kicker applet running constantly on one of 
my kicker panels, real-time graphing various system statistics and 
performance metrics including cpu (user/system/nice stacked together in a 
single plotter so the total of all three was also the total CPU usage), 
memory (app/cache/buffer stacked), network traffic, etc.

In early kde4, not only was there no plasmoid replacement for what I 
considered a very vital kicker applet, but even simply running ksysguard 
with the various plotters, etc I wanted and forcing the window position 
and always-on-top didn't work, as ksysguard itself was horribly broken!  
I remember that plotters didn't work well, for one thing, but there were 
a couple other problems with it too, that I've forgotten now.

Now it should be noted that while I said "early" kde4, this was *NOT* the 
kde 4.0/4.1 era, when the kde devs themselves admitted kde4 wasn't ready 
for ordinary use.  This was in fact late 4.2 and into 4.3, when the 
message was that kde4 was supposed to be ready for ordinary users, 
despite all sorts of horribly broken behavior remaining (and filed as 
bugs so the devs knew about them), including ksysguard's problems!   In 
fact, at the same time they were insisting that kde4 was ready for normal 
(as in, not beta testing!) users and that they weren't supporting kde3 
any more, on some bugs they were still saying that functionality critical 
to the way various users used kde hadn't yet been ported from kde3 yet!

Well, I've been running alphas/previews/pre-releases from the early MS 
Windows days when MS-DOS was still the primary OS (tho FWIW I left 
proprietary servantware behind and switched to Linux when eXPrivacy came 
out, as it crossed lines I simply wasn't going to cross!), both big money 
commercial stuff and single developer level, freedomware and servantware, 
and one thing I know about pre-release software is that if critical 
functionality isn't yet implemented, it's *NOT* considered release 
quality, ready for normal users, in fact it's not even BETA, that's ALPHA 
quality.  (Beta is commonly defined as the functionality basically there 
but still quite buggy, including critical bugs that may break the 
functionality for some; alpha as some functionality not yet there yet.  
Release candidate (rc) status is commonly defined as all functionality 
there and generally working, but some polishing still being done.)  So 
*FAR* from being release quality, kde 4.2 remained what is commonly 
defined as alpha, some stuff works, sort of, but critical bits of 
functionality remain unimplemented/missing.  4.3 arguably reached beta, 
most functionality was there but much of it was still broken.  4.4 
arguably reached rc status, almost everything worked, but some of it 
still needed polishing, and 4.5 was actually the first kde4 that I really 
considered proper release quality.

Of course making the problem many times worse was the fact that a kde 
spokesperson (Aaron S., president of KDE.e.v. at the time, IIRC, so about 
as authoritative a spokesperson as kde had) had pledged that kde3 would 
be supported as long as there were users... and then kde turned right 
around and dropped support after promising not to, despite all the users 
yelling that kde4 was still VERY VERY BROKEN, not yet fit to upgrade to.

Given all that... I along with many others ended up having to find all 
sorts of workarounds and alternative solutions as I was forced onto the 
still very broken kde4, and one of the things I ended up finding an 
alternative for was ksysguard, including the ksysguard kicker applet.  So 
as a result, I've not actually used ksysguard much in years, tho from 
your report, it's apparently still broken in pretty critical ways 
(assuming it's /not/ something as simple as tab/sheet update timing set 
to zero, point one).

So what ARE these alternative solutions?

For my more or less constant system status monitoring, I first turned to 
the YASP-scripted plasmoid (yasp being yet-another-system-monitor), 
available on kde-look.  Since it can be configured to print and/or graph 
the output from any command (such as sensors, from the lm_sensors 
package) that can be issued at the commandline, including the output from 
various scripts the user might wish to hack up, and it's quite flexible 
in how it can be configured to display that information yet somewhat 
simpler and easier to learn to setup than superkaramba, and I was under 
pressure to find and setup a suitable replacement for the kde3 ksysguard 
kicker applet, that was my first alternative solution.  It actually works 
very well, and if you look it up on kde-look, you'll note that some of my 
scripts still ship with it as samples that others can modify to their own 
needs.

Later, I switched to superkaramba, which is the same general idea as yasp-
scripted but somewhat more powerful and thus a bit more complex to setup 
and to learn.  Basically, a yasp-scripted applet stacks all configured 
output in the order it appears in its config file, so there's no 
positioning to learn and while you can control vertical order, to control 
horizontal layout you simply configure and run more yasp-scripted 
plasmoids side-by-side.  Superkaramba takes the same basic idea and adds 
layout elements, so it's possible to position any output anywhere in the 
superkaramba theme window.  To setup multiple plotters in the same graph, 
you simply set them all to appear at the same location.  That makes 
superkaramba even more flexible and powerful than yasp-scripted, but also 
more complicated to learn and setup.  However, having learned the basic 
concepts in yasp-scripted, superkaramba was then just a small step to 
learn, and I was able to do it at my convenience instead of having to do 
it under the time pressure of a forced and very broken kde4 upgrade 
because kde was dropping support for kde3.

I still use superkaramba for that purpose today.  A screenshot (warning, 
I run triple monitors in stacked config so it's big, 1920x3240 px, 4.5 
MB) with my superkaramba setup shown can be found here:

http://wstaw.org/m/2013/05/11/duncan-fullscreen.png

For the general process table functionality, I normally use htop in a 
konsole window (tho I've a short list, the top six CPU users and the top 
three memory users, displayed in the right superkaramba panel, but that's 
display-only), which someone mentions in a comment on that bug.  And of 
course ksysguard's process table (only) is available from krunner, where 
I activate it to check something or other from time to time.  But 
normally I'll just open a konsole window (I have a hotkey for that) and 
run htop.

For short term specific purpose monitoring I'll occasionally still open 
ksysguard, but really, most of what I'd monitor is already displayed in 
superkaramba, and I could probably uninstall ksysguard and wouldn't miss 
it much.

Finally, the third point/suspicion/hunch you might investigate, tho 
admittedly I've no real reason to point fingers in this direction except 
a hunch, and some people might view it as an unjustified accusation.  But 
I call it just one more possible lead worth checking out, just in case:

Namely, systemd, or more accurately, ksysguard's interaction with it, or 
possibly control-groups, part of the kernel but necessary for proper 
systemd functioning.

It's my general opinion (as an admittedly biased non-systemd-user, so 
take it for what it's worth) that systemd is growing too fast and has 
become too complex too fast for its own good, and the way it reaches deep 
into the system and interacts with control-groups, etc, is definitely 
rather far from the traditional POSIX methods, such that ksysguard may be 
interacting badly with it due to mis-matched expectations of how a Unix/
Linux based system and the processes on it are supposed to behave.

If for some reason various system resource tracking is being maintained 
by the cgroups or systemd (say total cpu time used by the cgroup, 
including processes now long gone), even after an application has 
finished running and no longer appears in the process list as seen by htop 
or ps, and ksysguard happens to be tracking those resources as it 
certainly does track at least /some/ application resources, it's 
/conceivable/ that ksysguard is somehow getting confused by the continued 
existence of those resources /due/ to that tracking, after the app itself 
is gone.

Additionally, systemd replaces the traditional init as PID 1, and part of 
what it does in that role (which init does traditionally) is become the 
parent of otherwise orphaned processes.  And one of the things a parent 
does is harvest various information (exit status, etc) from a finished 
app, before the kernel cleans it up.  If you've ever seen an app listed 
as zombie status in htop or ps, it's that harvesting and cleanup that 
isn't finished yet.

And it may well be that systemd behaves differently than traditional init 
in how it harvests such apps.  If ps and htop don't list them as zombie, 
then they are being cleaned up, but it's possible some aspect of that 
behavior differs from what ksysguard expects, thus leading to ksysguard 
continuing to see these ghost processes even after they're cleaned up and 
no longer reported at all by ps/htop/etc.

That could explain why it seems to be only ksysguard affected, not htop 
or ps or the like, since ksysguard's application detail display reports 
various stats that htop and ps don't track.  And of course ps is single-
shot, while ksysguard sticks around for possible errors to accumulate.  
Tho htop sticks around, but it's likely the person who reported that it 
didn't show the applications didn't run it for long enough to see if it 
was affected over the longer term as well, only long enough to check 
whether the apps that ksysguard was still showing were listed in htop 
too, which they presumably wouldn't be if it was started after those apps 
had finished. 

Finally, it's worth mentioning that various process information is also 
made available by the kernel in procfs, generally mounted as /proc.  
Someone who knew a bit more about how procfs works and what is supposed 
to be exposed there could check there to see if there's anything left 
around from these dead processes that shouldn't be, that ksysguard might 
be picking up.  At minimum, check that the PID for the dead process in 
question is no longer listed as a directory in /proc.

So perhaps compare notes with all the people on the bug, and see if 
you're all on systemd, and perhaps even all on the same distro (I saw 
fedora mentioned but didn't look closely enough to see if others were on 
say opensuse, gentoo, debian, arch, etc, or not).  Note that some distros 
(debian and gentoo that I know of) allow switching between initsystems as 
well, tho I wouldn't consider it an easy process.  But if per chance 
everyone on the bug is on systemd, and someone's on a distro that has a 
systemd alternative available, if they're up to trying to switch to 
something else to check if the problem persists or not, that might yield 
another clue.

But I'd consider everything speculated here in point #3 to be a 
relatively remote possibility; probably nothing to it at all.  However, 
SOMETHING is causing the issue, so SOMETHING is obviously not as 
expected, and these are just a couple more possible leads to check up 
on.  Maybe you'll get lucky and find that SOMETHING.

> 2.) Panels: Changed the "alignment" on one panel (for DualHead
> "mirrored" panel setup), one should think now the alignment is changed
> like in any other tool (mostly word processing tools I guess) but well,
> it is not, widgets and stuff still want to "fall" to the left. I guess
> because of that and other "bugs" there, several issues arise.

FWIW, I'd not think that at all.

In fact, quite the contrary, just because I switch a panel from one end 
of the edge its on to the other, does NOT mean I want or expect the 
individual plasmoids to change alignment within the panel as well!  I'd 
go so far as to consider it a bug if they did!

> http://forum.kde.org/viewtopic.php?f=67&t=94642
> https://bugs.kde.org/show_bug.cgi?id=248186
> http://askubuntu.com/questions/116040/how-to-right-align-widgets-in-
panel-in-kubuntu-11-10

In general panel plasmoid alignment and spacing in kde4 plasma has ALWAYS 
been buggy at best.  At this point I'm not sure it's even possible to 
make it work correctly.  I've simply resigned myself to it and gradually 
found my own workarounds and/or configurations that work "well enough" 
for my usage, despite the continued spacing behavior issues.

One of the workarounds for me is that I don't put much on the plasma 
panels any more.  In fact, I only have one single plasma panel, quite 
small and set to autohide, bottom left.  I run superkaramba as a stand-
alone app, instead of running it as a plasmoid and trying to place it on 
a desktop or in a panel as is also possible, as that allows me to 
configure it as a docking top "panel" of its own, always-on-top, covering 
almost all of my top monitor (of three), as seen in that screenshot I 
linked above.  Superkaramba in standalone mode seems to behave rather 
better as a panel than it would as a plasmoid, so that's how I run it. 
(Among other things, plasma panels appear to be limited to 1/3 of the 
monitor they're on, and my superkaramba theme takes up about 90% of its 
monitor, with only a bit of desktop exposed below it to give me a spot to 
desktop-scroll between virtual desktops (scroll-wheel-only, as configured 
here) or activities (ctrl-scroll-wheel) when both bottom monitors are 
covered.

My single small plasma panel is docked to the bottom, positioned left, 
perhaps 25% the length of the bottom edge, and set autohide.  It has only 
the kickoff icon, a classic launcher set for bookmarks only, notification 
and systray, a spacer, and clear to the right, a quicklaunch plasmoid 
(from kde-look, it's a variant of the folderview shipped with kde, that I 
like a bit better).  The spacer is set to flexible size so that it'll 
absorb the expanding size of the systray as more icons appear in it, and 
at least on 4.11 (and 4.10 before that), with the help of the spacer, the 
quicklaunch icon seems to behave itself and stay far right.

(I don't use a task manager plasmoid at all, instead using the primary 
and alternate window switchers (alt-tab and win-tab), desktop-center-
click-activated-windowlist, virtual-desktop-switching, and the fact that 
I have a HUGE triple-monitor desktop with two of the monitors actually 42-
inch full-HD TVs (!!) taking up the full wall they're mounted on in front 
of me and the third a smaller but same resolution monitor logically 
stacked on top but physically off to the side (that's the superkaramba 
monitor), thus giving me room for four half-maxed windows, with focus-
follows-mouse, to avoid needing a task manager.)

If the quicklaunch to the far right didn't work, however, I'd work around 
the problem by ordering the notifier/systray last, but perhaps for the 
spacer.  I'm glad it's working as I prefer the quicklaunch off to the 
right by itself, but I wouldn't consider it /too/ horrible if that didn't 
work and I had to do the workaround thing.

What's worth noting, however, is that other than the flexible spacer, 
there's only one dynamically sizing plasmoid in that list, the systray, 
and from my experience, that helps a GREAT deal.  Once you get a second 
dynamically sizing plasmoid on a panel, plasma doesn't seem to be able to 
reasonably allocate space any longer, and everything seems to go 
haywire.  So the fact that I only have the one dynamic sizing plasmoid in 
my panel could be called a workaround, or it could be called me simply 
finding a layout that works for me, which happens to work around a 
spacing/alignment problem as part of the bargain, but either way, it IS a 
solution that works well for me, so I'm happy. =:^)

> 3.) Widgets, plasmoids, generel KDE features: Yeah well, really nice
> design (mostly), but from a usability standpoint? Often a mess. First
> one sees a feature and thinks "Great" and later on he might realize how
> bad that feature is implemented. I don't want to get into details yet,
> as this mail is going to be long enough already, but if there is any
> need and someone has no idea what I am talking about here, just ask. But
> remember, I don't say all and everything is implemented badly, with
> KDE-stuff it just looks to me the tendency is there that stuff gets
> implemented in a rather weird / bad / less- to un-usable way.

FWIW, my thinking on this is that it just happens that the kde devs (and 
in particular the plasma devs, since that's the desktop kde uses) have a 
particularly bad case of one of the traits very common to free and open 
source application development and the developers behind them -- the 
"developer scratches his own itch and stops when it stops itching for 
him" phenomenon.  As you're likely aware, this is in fact one of the 
criticisms leveled at free and open source software by proprietary 
servantware and commercial software developers -- that the "scratch your 
own itch" model doesn't properly serve the non-developer user.

Those commercial/proprietary model proponents do have a point, that IS a 
weakness of FLOSS, but I believe it's a rather limited point, because in 
practice, the negatives of proprietary servantware such as the fact that 
it's designed with the owner's interest in mind *NOT* the user's 
interest, thus things like DRM, ad-ware, spyware, register-or-deactivate-
ware (eXPrivacy and later being the headline example), call-home-for-
permission-to-run-ware (eXPrivacy and later again), tend to FAR exceed 
the to me rather small in comparison problem that much FLOSS is scratch-
your-own-itch-ware.

Anyway, yes, I think that a lot of the user-visible problems with plasma 
in particular, as well as early kde4 fiasco beyond plasma and to some 
extent kde4 even as it exists today, are the result of developers with a 
WORKSFORME, it /must/ be ready to ship, attitude.  And that problem, 
apparent in kde4 as a whole especially in the early days, seems to be 
particularly bad with plasma.

> 4.) Weird messages and... stuff: Be it annoying phonon messages that a
> audio device was removed, though it definitely was NOT, power-manager
> framework telling me it doesn't work because of... yada yada, but it
> does work nevertheless, starting others DEs stuff while KDE is running
> (or the other way around) might screw things up bigtime, configuration
> tends be be trashed every now and then, from one moment to the next (in
> the process of configuring KDE for example, so no change to the
> installed packages or other changes to the system) KDE may start to
> behave "weird". Like starting KDE-apps (dolphin) takes several minutes
> while other apps just start fast as before, context-menu might need
> *minutes* to open, shutdown-, reboot-, logout-popup takes minutes to
> show...

Remember up top where I said I'm a *HEAVY* customizer?  It reflects in my 
distro choice -- gentoo, as well as my desktop choice -- kde. =:^)

One of the great things about Gentoo's customization is that on gentoo, 
various compile-time support and resulting dependencies can be configured 
on or off via USE flags, which make it a relatively simple process.

And with gentoo/kde, one of those USE flags is semantic-desktop (tho the 
gentoo/kde folks tried to remove it and hard-enable semantic-desktop at 
compile time for kde 4.11, and I was for a time forced to carry my own 
patches to force-disable it, but fortunately sanity eventually returned 
and it's again an option).

I've also disabled the policykit USE flag as well as upower, udisks, 
etc.  There are some functionality tradeoffs, but it makes for a far less 
complex and buggy kde, and I prefer stuff like manual mounts and my own 
hibernate scripts in any case.

And you know what?  Without all that junk even built at compile time, the 
problems I had with kde went down DRAMATICALLY, and performance went up 
as well.  That's why there was NO WAY I was going back to semantic-
desktop when gentoo/kde went temporarily insane and tried to hard-enable 
them, even if it meant switching to some other desktop as a result.  
Fortunately, however, I'm now experienced enough that I was able to find 
and carry the patches necessary to disable it, so I didn't have to leave 
kde, and even more fortunately, the gentoo/kde insanity proved to be only 
temporary, and semantic-desktop is once again a supported togglable USE 
flag. =:^)


But plasma, in particular, still likes to lose settings once in awhile.  
Workaround time!  I ended up setting $KDEHOME/config/plasma-desktop-
appletsrc readonly, and fortunately kde respects that, and I don't lose 
my plasma settings any more. =:^)  There's a couple minor side effects 
such as the comicstrip plasmoid not updating its record of the current 
strip, so when plasma starts it has to figure that out on its own each 
time and it might take a bit to do so, but it works.  I also have to 
remember to set it read-write temporarily if I want desktop wallpaper 
changes to "stick", but with the picture-of-the-day wallpaper plugins, 
that's not too bad, and now I can do things like temporarily add a new 
plasmoid to my setup for the in-memory plasma only, to test it for a 
reply to a message here, say, without having to worry about the 
possibility of that screwing my normal config, since all I have to do is 
restart plasma and it's back the way it was.

And there's a number of folks now cced on a bug I filed back during the 
kde 4.11 betas about plasma forgetting its configured activities and 
starting up with a default new activity, as it's happening to others too, 
now that kde 4.11 is hitting the big distros.  But restarting plasma 
after kde gets running works fine -- I get my old activities back.  So 
the workaround there is two-part, another file ($KDEHOME/config/
activitymanagerrc, IIRC) set read-only, so I don't keep getting more and 
more new default activities added to the existing activities each time I 
restart kde, and a script setup in the startup dir, that sleeps a couple 
seconds, then kills and restarts plasma, so I get the customized 
activities along with the new default activity it still insists on 
creating.


And... another bit of fallout from the early kde4 fiasco that hasn't been 
resolved yet.  I happen to have one of those newfangled "internet/media" 
keyboards with all the extra keys, and in kde3, I had khotkeys setup to 
use one of them (XDG_HOMEPAGE, IIRC) as trigger or menu key, for a bunch 
of others.  So for example, I could hit homepage, b, to launch the 
browser, homepage, p, to launch kpat, homepage, c, to launch konsole, 
etc.  Without the ability to setup that multi-key hotkey with the trigger/
menu key followed by something else, I'd only be able to assign a single 
app to that hotkey, or perhaps a couple more if I used modifier-key 
sequences as well, instead of the dozens I had multiplexed on the same 
trigger key!

But khotkeys4 could no longer handle multiple keys like that, and all my 
carefully multiplexed two-stroke hotkeys broke! =:^(

It took me a while to figure out, but eventually I realized that if I 
could setup a configurable menu on just the homepage key, with that menu 
in turn taking another key, I could chain the effects together and get it 
to work very nearly like it did in kde3.

But I'm a user and sysadmin, not a coder, so I couldn't just hack up an 
app in C/C++ to launch the desired secondary menu. =:^(

Workaround time!

Eventually I hacked up a multi-part solution.  I set a first-stage khotkey 
with the XDG_HOMEPAGE key, to launch a bash script (as a sysadmin I CAN 
code those up!) in konsole, that reads and displays the menu I've 
configured and waits for exactly one key.  When it sees a key, it 
compares that to its list, and launches the application associated with 
that key.

I ended up chaining three keys deep, HOMEPAGE activates the menu script 
with the default menu, which is simply a list of other menus based on 
category (g=games, n=net, m=media, etc).  Then I press the second key, 
say g for games, which calls the script again, this time with the games 
menu.  There I press say p for kpat, or (shift-)P for palapeli, and it'll 
launch the associated app, kpat (p) or palapeli (P), in this case.

So the full sequence is HOMEPAGE (first menu), g (games menu), p (kpat).  
Three keys to launch kpat or any other command I use frequently enough to 
be worth configuring a hotkey for. =:^)

But while it works, the fact that its a shell script means the response 
isn't as fast as a C/C++ based app would be, and of course I get the 
"ugly" text-base menus instead of something graphical, with icons, etc.  
It's definitely a hacked up workaround, but unlike khotkeys4 which 
*STILL* can't manage multikeys, it actually WORKS!

> And a bunch of other stuff that might just happen when using KDE that
> somewhat feels... well... awkward, weird, annoying. Bottom line, it
> feels like a lot of rough edges and that those edges might be smoothed
> out eventually, but apparently it looks like they don't, as where I
> pointed out links to bugtracker or forum-posts, the issues are as old as
> Methusalems grandpa.

I'm snipping the rest, but I definitely agree with most of it, and while 
my sore points are different than yours, I certainly do have them, rubbed 
raw by all those kde rough edges!  So I definitely feel the pain!

-- 
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

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.