KDE 4.3: More ranting Review & Comment.

KDE turns 4.3

I've already ranted about how awesome KDE 4.2 was, so this is an update for what I'm currently doing with KDE 4.3RC2. So far I'm liking a lot of it, but I also want to share my own grievances. At this point I think KDE has the greatest potential of any desktop system I've seen (be it Linux/Mac/Windows) to really be dominant, and even make the jump from conventional desktops to mobile devices without having to be completely rewritten. However, I'm tempering all of this with some pleas on how KDE may be better off with fewer features, as long as those features are working 100%

How KDE 4.3 Customizes for my own Tastes:

Here's my basic desktop, note the lack of a standard panel:

A few words on how this desktop is laid out. I'm using the new AIR theme right now, which is the new default for KDE 4.3. A lot less black than the previous Oxygen, and I'm finally happy with a default KDE theme choice (although there are still plenty of additional themes available). I do not use any of the "normal" KDE program launchers, and I don't have a panel with a taskbar either. So how do I get anything done? That takes a little explanation.

For managing windows, since I don't have a taskbar, I re-mapped the "scale window" keyboard shortcuts to the F9 and F10 keys. F9 is for selecting all windows on my current desktop, and F10 for all available windows. These effects also restore minimized windows, so no need to worry about minimized windows disappearing forever. The ALT+TAB combo still works too and I can traverse windows in a list that way. I actually find that these tricks are a good bit faster than hunting for the right window on the taskbar. I need far less mouse interaction to jump between windows than using the conventional workflow. Once windows are presented, filtering can be done by typing in the window's title (a feature adapted from Compiz) EDIT:(a feature that was copied by Compiz, thanks to sebas for pointing this out).

To actually run applications I have two major methods I use from the GUI that have made things like the "K" launcher superflous. First, along the bottom you see my Daisy quicklauncher. Daisy is a very nice application launcher plasmoid that I've configured to act as a simple program launcher. It can be configured similarly to the OS X dock, but I only use it to quick-launch common applications.

So what do I do if an application is not on the quick-launch bar? I use the amazing krunner application that is my new Swiss-Army Chainsaw for running things from the desktop. Krunner does not require you to type the exact name of a command to run, it can look at any application with a .desktop file and use words to associate the application with what you want to run. Some of these features are already present in KDE 4.2, but krunner in 4.3 appears to be much more stable & versatile:

Krunner has a plethora of other functions that are too numerous to fully outline here, but it can also act as a calculator, currency converter, and even a shortcut to Google or Wikipedia searches:

Things That Need Attention

So, as with every release things are improved but not perfect. While a project like KDE can never truly be "finished" a few things could stand to use some polish. These requests are not really for new functionality, just to get the currently advertised functionality working properly.

First: Nepomuk needs a massive amount of attention. I won't lie, I turn the service off right now, but for experimentation, I turned it on and let the Strigi indexer churn through my harddrive for 15 minutes. After that was done, I opened up a simple Nepomuk search, and tried typing in a single word search ("Major") which, being a common word, should have turned up matches in several documents. Unfortunately, the search ran for 45 minutes at 100% CPU power and produced no results. I killed it at that point, and I'm hoping that my (rather modest) collection of files isn't too much for Nepomuk to handle. The theory behind Nepomuk is interesting, but if it is going to actually deserve to run on my desktop, it better work right, and not hog too much RAM in the process.

Second: While I don't use kmail or the KDE PIM suite, I've heard horror stories about Akonadi and the need to have a full-blown Mysql server running just to look at email addresses: Not cool guys, get the bloat out. Any address book so complex that it needs a Mysql database is going to be on a centralized LDAP server to begin with anyway.

Third: Work on the uncool stuff, even if it isn't as much fun as the latest plasmoid. Let me explain by example: the kio_http utility had a bug that would cause it to go to 100% CPU usage when invalid gzipped data came down the wire. This affected many higher level applications, including my favorite yAWP weather plasmoid, that I much prefer to the KDE default.

So what is the problem with this bug? Well... it was a basic coding oversight that failed to check for a well-known error condition that had a pretty obvious negative impact on the system. The bug was first reported on November 24, 2008... and the original bug report pointed out the SPECIFIC CODE that was broken! Here's the problem: the fix wasn't put in until July 5, 2009.. that's over seven months with a bug that was widely reported (see all the duplicates of the original) and that was a basic error in not checking return values. This is the type of programming that isn't necessarily "fun", but it is vital to making sure that people actually want to use KDE. See below for more on how I'm afraid people are too focused on the newest social-networking plasmoid and not enough on making stuff work.

Another basic problem that I fortunately have a work-around for is that the KDE Network manager plasmoid is STILL in a state of disarray. I know that the developers are working on some major updates for it, but in my own experience the plasmoid has actually regressed from the KDE 4.2 days. Using the current SVN tree, the plasmoid will run and detect wireless networks OK.. unfortunately it will absolutely refuse to accept my WPA passwords and actually connect to those networks. I have kwallet open, I have 74 prompt screens asking for the passphrase over & over again, and I have no working connections. I have to use the gnome nm-applet program right now, which works just fine and even allows for proper secure-caching of WPA passphrases so I can autoconnect. Getting on a wireless network is a basic task that anyone with a laptop needs to have working, and when it comes to priorities, this should be at the top of the list.

Finally: RESOURCES, RESOURCES, RESOURCES. I'm not exactly what you'd call a tree-hugging hippie, but when it comes to my system RAM, I'm all about conservation! Most of my problems are not directed at KDE itself, but with the combination of Qt and X.org which seem to enjoy frittering away memory and then never releasing it back (short of me killing the X server entirely). Unfortunately, since KDE is based on Qt, it inherits all of these problems. However, there are some things that the KDE developers could do to minimize resources:

• Kill off those annoying kio processes! I know that they are supposed to time-out on their own, but I suspect that when I suspend/resume my system, the timeouts fail and I have a bunch of kio_https lying around that are doing nothing. These things should open, do a specific task, and then bail. The same goes for kio_file, kio_thumbnail, and kio_trash processes... get the job done and then EXIT properly.


• Here's a minor but annoying one: Kwrited... a background daemon using 18MB of resident memory to catch and give a fancy gui to the old-school "write" command on the terminal. OK, I guess it's cute for the systems that still bother to use this stuff... but allow me to TURN IT OFF! As it stands I kill it and delete the executable every time I upgrade KDE now....


• Shared Memory Hogging: I use the (very common) binary Nvidia graphics drivers that are not compiled with -fPIC, meaning every Qt app that I run loads up roughly 10MB of non-shared code sucked in from the Nvidia drivers. Yes, I wish that Nvidia would fix this, and I'd even buy a faster card if it really hurt performance (Nvidia you're losing money)! However, since this is apparently not in the cards, I have heard that it could be possible to have a parent launch program that takes the memory hit one time, and then forks processes that can still share memory. This would be great for the little programs like klipper, kmix, etc. that are all very small, but are still sucking down 16-20MB each... that usage adds up quickly

My Personal Plea for KDE 4.4: Quality NOT Quantity with the Features!

When KDE 4 first appeared the two major criticisms were that it was different than the 3 series, and that it lacked features of the 3 series. KDE 4 is going to continue to be different than 3 in many ways, but more and more people have come around to realizing that its differences are mostly for the better. On the feature front, most of the important features from KDE 3 have already been brought over, and KDE 4.3 adds in a few more ones that people were missing. There might be a few features left out that some people find important, but at this stage all the basics seem to be implemented... however the quality of the implementation is another matter that I think needs addressing. I think that the developers have been in a headlong rush to develop new features, but that it is coming at a cost to system stability that is starting to take a toll.

I won't repeat my criticisms from above about specific bugs that are annoying me, and are long-standing issues that have not been fixed. The point here is that KDE 4 is actually ready from a feature perspective, it is just that the quality of what KDE has got needs to be honed to be faster and more reliable.

I'm not advocating that there should be no new features in KDE 4.4! I'm just saying that at this point, the marginal gains to KDE from improving speed, stability and bugfixing plasmoids to "just work" are going to make a more positive impact on the user experience than rushing off with some new plasmoid or huge database project that leaks memory. One good example I hate to point out is the new social-networking plasmoid that has gotten a good bit of attention lately. I'm not saying that it shouldn't be developed, but I am saying that when basic plasmoids like the weather forecast plasmoid have longstanding bugs and are lackluster compared to third-party plasmoids like yAWP (which can't seem to get included in the KDE default branch) then there is an issue with developer priorities. While making existing features work right is not as much fun, it is probably a better way to win new users than yet-another social network that happens to have a plasmoid.

Another one of these half-done features deals with plasma workspaces and how they do or do not map to virtual desktops. I (think) I get the notion that plasma workspaces are supposed to support independent plasmoids, while virtual desktops are for organizing regular windows. Unfortunately, I've never seen any value in using the cashew to (akwardly) zoom in and out of workspaces that often appear to pop into existence at random. I'm sure this is useful for developers that want to debug plasma, but from an end-user experience I don't want two separate and confusing paradigms for moving between workspaces, I want one that works right. I've messed around with the separate plasma workspace on each desktop option, but it's never really behaved correctly. This feature could be useful if it was done right but it's actually a hindrance to even have it at all if it is done wrong.

Incidentally, I'm not only criticizing KDE specifically here, as other projects have the same issues. Look at my screenshots and you'll note that I like music, which is why I'm using juk and not amarok. When amarok developers think it is more important to use 1GB of RAM to play music, while simultaneously not even having a basic equalizer plugin, I give up. I'm not saying that Juk couldn't use more features, but I'm willing to bet $100 that the vast majority of users want a feature like a solid and reliable equalizer plugin that could have custom profiles for individual tracks over the ability to add a facebook plugin any day of the week. KDE's Juk wins with me because it is easy to use and reliable at what it does.

I also want to point out that several new features are very helpful. KDE 4.3 has some nice improvements that DO focus on making the desktop experience better, and the folder-view plasmoid is an excellent example. A folder within a folderview can now be accessed without having to open the full file-manager, and executables on the desktop now come with a red exclamation mark and a warning before being run the first time. These types of features have a direct impact on making the desktop both more functional and more secure... this is exactly the type of innovation that directly helps the desktop experience, and KDE 4.4 really just needs more stuff like this to really shine.

KDE: The OS X of Open Source

For anybody who thinks I'm being too harsh, I want to pay KDE 4 a huge compliment: I think that the 4 series now has OS X like status... and no I don't mean it's overpriced for hipsters :-) What I really want to say is that OS X started in a similar situation to KDE 4 in that it had an entrenched userbase who loved its predecessor, but while the early versions of OS X had a lot of promise, they also lacked many things that the userbase were used to. As time went by, OS X's feature set filled in and as of 10.5 the biggest issue that most people have is that there are too many features that are not fully "just working" for many users. Hence, the Snow Leopard release that is not so much focused on the latest whiz-bang changes, but on getting the existing features refined, and doing it all faster.

I think KDE 4.4 can be a Snow Leopard-esque release for the K developers, that really works on refining things to be smoother for the end-user without having to focus on huge changes. KDE 4.3 is looking better (always a positive) and if 4.4 focuses on making KDE leaner, meaner, and more refined it will be the type of desktop that nobody will be able to say no to!