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.