Three reasons not to use KDE

Hello! Remember me? I'm the guy who wrote Three reasons to use KDE. Yes, that's me in the picture.

This time, I'll exercise my mind by coming up with three honest reasons not to use KDE. Of course, this is not an original idea either, since it was inspired by Three reasons not to use GNOME -- I tend to derive my inspiration from third parties. Since I'm a bit drunk, I won't make any promises as to glaring style or logical errors, but I'll try and keep my spelling in line. And, without further ado, let's get on with it:

Web browsing

Everyone who uses KDE has used Konqueror, in one way or the other -- most probably in its file manager role. And, while Konqueror excels at being a versatile file manager, Web browsing can sometimes be a pain.

Let's face it: a lot of Web sites with JavaScript have serious bugs. I'm going to go out on a limb and state something that should be fairly obvious: JavaScript encourages sloppy code. And there's a lot of sloppiness out there in the big World Wide Web:

• Web sites that contain IE-isms.
• Web sites that use language/runtime features without checking if they're available first.
• Web sites that check for and cater to both IE and Firefox, but no other browser.

Guess what: usually, it's both Konqueror and Safari (which share code) the ones that are left out in the code. I, for one, cannot use my bank's Web extranet.

Of course, there's Firefox. All I have to do is drag the URL of the problematic site onto my panel's Firefox icon, and up comes Firefox, ready to challenge the evil forces of Web proprietarianism and imbecility. Usually, that does the trick.

I'm fully aware this is not really a KDE or Konqueror issue, but rather the Web site author's fault. But whom do you think is going to take the heat for failing to render buggy Web sites properly? In about 99.9% (numbers pulled out of my ass), it's Konqueror instead of the buggy site.

And here's a valuable suggestion: Konqueror should complain loudly when it encounters a JS bug. Konqueror should boldly and arrogantly state in uncompromising terms: This Web site is broken, and add a short explanation -- understandable by non-techies -- as to why this could happen. At the very least, this kind of message motivates users ro report broken Web sites. Oh, did I mention that the explanation should warn users about lame Web masters that say "Konqueror is unsupported"?

Clutter

There. I said it. Make a non-techie user visit the KDE control center. It's an exercise in fun at the expense of others. Yes, there are navigation aids -- such as the search box atop of the sidebar -- but they just don't cut it. Just open any control center applet and you'll find a myriad options, some of which don't have context-sensitive help aids. Never mind that the question mark in the titlebar is so inconspicuous as to being close to undiscoverable.

Moreover:

• The wording of most options is fairly technical.
• Some options can be nuked by clever programming. It's all a matter of never asking users to choose when the computer can make an informed decision. By the way, kudos to the KDE team for nuking KPersonalizer in KDE4. It's an unexpected interruption at first login, and it really doesn't help the user very much, seeing as the great majority of KDE newcomers have a Microsoft Windows background.
• Some other options (but not most of them) should plainly disappear from public view. I'm perfectly sure that the KDE developers are thick-skinned enough to take a bit of heat from users who complain about the disappearance of their pet setting. I'm also convinced that the KDE developers can choose sensible behaviors for 99% of their users, thus succesfully reducing the different ways their software can behave. It'd be good for software quality processes, since a simpler application with frequently exercised code paths it's easier to debug than a complicated applications with seldomly exercised code paths.

Applications have similar malaises. Even Konqueror, posing as the file manager, has way too many buttons in its toolbars. Guys, just make the buttons bigger and slash some of them. Advanced users can still right-click on the toolbars and add their pet buttons. Of course, weeding out the unused buttons will take some usability research.

This should have been fixed as of yesterday. And I'm positive that the KDE people will fix it, eventually. It's just a question of when.

Speed

I'll admit it. KDE feels faster than GNOME, especially when using remote resources, file shares and Web sites. Yes, I said Web sites: Konqueror consistently renders them faster than Firefox.

Actually, I may be exaggerating just a little bit. Konqueror tends to avoid rendering incomplete pages. When the Web page's data downloads fast, Konqueror beats Firefox. But Firefox's incremental rendering in the face of incomplete Web site data still beats Konq any day.

And, of course, the expert KDE devs should continue to optimize application load times. The fact that they're using C++ has historically put them at a techincal disadvantage against C-based apps (such as typical GNOME apps like Nautilus), from a perspective of application load time. Yet they're still defying the status quo:

• They've come up with ingenious ways to work around slow application loading times. The famed kdeinit (which is optional) is a good example.
• They've lobbied continually to push their discoveries down the dependency chain (e.g., into the linker and other system libraries). This kind of effort benefits us all, not just KDE users.
• They continually run their most representative applications under valgrind to weed out errors, memory leaks and performance problems.

Here are three Issues to keep in mind when optimizing:

• Reducing memory usage. Try to share as much code as possible.
• Reducing disk fetches. Icon and font caches go a long way, but there's got to be a way to reduce disk accesses upon application startup.
• Providing better user interface clues for lengthy or potentially asynchronous operations.

Conclusions

I know, I know... the title of the article is deceitful. I haven't managed to find a single powerful reason to avoid KDE altogether. You see, KDE is quite good. Of course, if anything above this paragraph discourages you from using KDE, so be it, because it's all fact. But, before abandoning KDE like a rat in a sinking ship, I honestly think you should make an informed decision, and the best way to do so is to experience KDE in the flesh.

However, I certainly think this short piece has managed to:

1. highlight the (frequently underappreciated) efforts that the KDE project has consistently exercised,
2. convey facts (with decision-making and opinion-forming value) to both existing and potential KDE users, and
3. point future KDE efforts in (what I consider to be) the right direction.

What? Were you expecting any sane conclusions from an article I quickly cobbled together in ten minutes? If you did, you were wrong, my friend. Talk is cheap, so it's up to you to voice your conclusions in the comments area. What are you waiting for?