KDE 4: some reasons for design decisions

The first KDE 4 release will come along with several major changes compared to KDE 3.x. While explanations for these changes have been posted at several places before there is a central list missing which explains the reasons to normal users. This post lists some hot topics and tries to shed some light on the reasons behind certain decisions..

KDE 4 will be a large step away from KDE 3 in several regards. I already posted a short list of programs and services which will be replaced by something new. However, that list didn’t say much about the reasons behind these decisions. But with the ever closer coming release date of KDE 4.0 and new and easy ways of testing the newest builds many people in the last days asked questions at different places and occasions and wondered why beloved KDE 3 technologies will not appear in KDE 4 anymore, or why certain services have been exchanged against something new. Even a friend of mine a normal users who do not follow the development of KDE 4 closely, raised some concerns. Last but not least there are active discussions going on at the KDE planet about this topic atm. This post sheds some light on the reasons behind some of the design decisions for the user point of view.

arts vs Phonon

That one is easy, and therefore it is good for a start: aRts, the KDE 3 soundserver was powerful, but simply unmaintained. Despite its superior technology when it was introduced for the first time it was out-dated when KDE 4 development started – video support was for example missing, to begin with. So arts would have required a major rewrite in almost every regard with many new features to add to get into a future-ready shape. And there was no one really willing to do that. At the same time other very capable and promising multimedia frameworks were available (Xine, Mplayer) or in heavy development and almost available (Gstreamer).

Also, having a fixed dependency on arts only hurt KDE 3 to the end of its life time very much. The KDE developers felt like that this should never happen again. So it was decided that the best would be to write a wrapper. And someone stepped up and did exactly this. Phonon was born.

The question is of course if it turned out to be the right thing. Time will tell, but the fact that Trolltech already decided to include Phonon in Qt 4.4 in some bits is very promising.

kcontrol vs systemsettings

That one is not that easy at all: kcontrol will be replaced by systemsettings, and several people don’t like the new systemsettings. Having said that, these people should have a second look at the moduls themselves: systemsettings just loads the modules of kcontrol. So the frontend which offers the modules is different, while the modules stay the same (but are of course also improved for KDE 4). The reason behind this move has to do with development power and also wishes from the users: systemsettings was introduced with Kubuntu for their modified KDE version. Many users indeed liked it since – for them – it was more polished, usable and easier to understand. kcontrol, on the other hand, didn’t have a maintainer.

Of course, long time KDE users had mixed feelings – people like me, who never really got the hang with kcontrol like systemsettings, others are more used to kcontrol. But in the end the mass of the users of the system tool will be users. Normal users, not power users or developers. And after all I’ve read about both configuration tools it looks like that most normal users don’t really care since the functionality is basically the same and the modules are the same. So, they don’t really care, plus there is no maintainer for one of two solutions, leaves us with the other solution.

Oxygen

This one is tricky: Oxygen is most visible by the used iconset and the theme, and the above mentioned friend mentioned that he didn’t like the new theme. In contrast, I prefer to have a very bright, almost milky theme and I don’t need much contrast (what for anyway?). But we are both power users, and we do know that switching to another theme is done in just a few seconds. And the new theme engine is very powerful! But for the average user it has to be pretty – and for these people a milky theme with not too much contrast seems to be equivalent to the term “good design”. Additionally, some of the top KDE designers have a similar feeling and also wanted to test there abilities in that field (I guess). So the decision was there. And why not? Every power user shouldn’t bother with any theme or icon dislikes because he/she also knows kde-look.org.

So the only thing which has to be made sure is that KDE 4.0 comes along with a set of different icon sets and themes to please more than just one user base. Or maybe just with GetHotNewStuff buttons.

And as a personal note, because I was asked this quite often: the big icons inside Dolphin which can be seen on several screenshots are there because it looks better on a screenshot. Of course I would never use such big icons, and of course Dolphin does not force such big icons, and of course it is not part of the look of KDE 4 to have big icons!

Kicker vs Plasma

KDE 4’s panel is a hot topic which was also discussed between several KDE developers the last days. The problem is that the current Plasma replacement for kicker is not on pair with kicker feature wise. So why was kicker dropped and something new created instead of just improving kicker?
The reason is that kicker was already broken years ago: the code was hardly readable, and new introduced features often introduced bugs and problems at other places. Also, kicker was as flexible as a mountain: several projects which aimed at adding a cool new feature to kicker in the end copied the code base and started to rework it on their own – they forked kicker. And that would not have been necessary when kicker would have a better design for such improvements. But kicker was created for KDE 2.0 (!), at a time when no one would have thought that some years later applets would be embedded in the panel as well as in the desktop. Or that there are indeed several ways to provide panel functions and not just the 90s like static attempt (think of MacOS like approaches, etc.).
In contrast, KDE 4 will have a long life cycle, and therefore all code must be maintainable for a long time – and for other developers.

So the options were to either totally rework kicker from the basic design through the entire code base up to the applet part to check if parts can be shared with Superkaramba. Or a replacement could have been provided. But, and that is important: there was no way to simply keep kicker, because it was not in a maintainable state for KDE 4.
The decision was as usual done by the people who provide the code: people decided to merge the desktop with the panel and provide everything from one point. That was quite a bold decision, and a lesson to learn: while Plasma makes great improvements every day, it was and probably still is one of the most criticized features of KDE 4. There are still some bits missing until it is ready for release.

From a user point of view it will be something new to get used to – some features of KDE 3’s kicker will most certainly be missing. Of course, all the basic panel stuff will be there, but it will still be an entirely new panel. Nothing more, nothing less. You must get used to it, and it will take time – at least a bit time, even a Plasma panel is still a panel. However, one of the advantages of the new technology is that it was designed to be much more flexible than the old one. So in the long term you can expect various of customization feature coming up. And even if there will be new ideas to implement the basic panel functions these will not require you to replace the current panel but will (well, hopefully) simply build upon it – unlike KDE 3’s kicker replacements. So even revolutionary new ideas might integrate into the original system without much work.

And in case you worry about the current design: it is not final. Plasma is themable and it is not yet said how the final version will look like. Maybe it will even be significant different from the current design to distinguish itself from the Beta/RC design.

KMenu vs Kickoff

Another source of hot emotions: The problem here is that KDE 3’s classical menu (90s style) will be replaced by a Kickoff port which was originally developed by OpenSuse/Novell and used in recent OpenSuse distributions. People who are used to the classical menu style either by older Windows releases or by KDE 3’s menu will be at least confused when they first use Kickoff. Many of them got annoyed since it does not behave like other menus.

So, why the change at all? Again, one part of the answer is the code base of the old solution: it was, according to the developers, ugly. Additionally, Novell spent quite some money and time on the question how a menu actually should look like usability wise. They checked back with users (like, real people, not computer people 😉 ) and tried to figure out what actually is usable. Most people like the classical menu because they are used to – that has nothing to do how well this type of menu is actually suitable to the task. And usability wise it is totally nuts to navigate such menus with a mouse! (Do I have to add that I don’t use menus at all as long as I can avoid it? Long live Alt+F2!) So they started developing Kickoff – with average or new users in their mind.

In the end the situation was that usability wise Kickoff was a strong improvement to the old menu. It doesn’t matter if you disagree with that personally, because that has nothing to do with the figures gathered in a scientific test. Also, there was developer power there to port Kickoff. And they did.
Originally, there was even another menu planed, but that was delayed.

So the situation is quite nice for new users. It sucks a bit for power users, but for them Plasma will maybe save the day: with Plasma it should be fairly easy to replace the menu by another one. Indeed, there is already another menu/application launcher in development, Lancelot. Also, it was mentioned that it should not be too difficult to implement an old-style menu, for the people who love the stone age (90s) but want to distinguish themselves from apes (command line or Alt+F2).

Konqueror and Dolphin (“and”, not “vs”)

Dolphin will be KDE 4’s new file manager. And many people raised concerns about that. Especially the power users fear that Konqueror might get neglected now, which would be horrible. And I agree, btw., that such a thing would be horrible: Konqueror is the swiss army knife for everything file management related. It is *the* tool for power users.

So, first of all, why was Dolphin introduced at all? The first reason is that Dolphin, formally a third party development, got quite some attention and was very popular especially when KDE 4 development started. The second reason, and the developers realized it when Dolphin became that popular, is that many users just want to have a simple file manager and not a swiss army knife for file management. Also, there was a chance to improve Konqueror’s file management by inviting Dolphin’s developers: Konqueror will use Dolphin’s file management engine to manage files. This will improve Konqueror’s abilities in this regard – and will make sure that Konqueror will not fall behind (that is the mighty technology of KDE 🙂 ).

Of course it is not bad to keep an eye on Konqueror’s development to make sure that no one forgets it due to the excitement for Dolphin. But recent news show that there Konqueror is polished and equipped with new features.

Closing thoughts

This list covers the most important topics. There are of course more things which are occasionally discussed, but this list is a good first start I guess. Also, the list is already quite long 😉
I do however want to add that most of the information here are the impression I got from reading blogs, commit digests, comments, etc. Remember, I’m not a KDE developer. So if I forgot an important reason or mixed something up, please leave a comment and I will alter the text here. Also, some of the reasons depend on interpretation and personal point of view of the developers, so some people might disagree with the point of view and the reasons offered here. In such cases you are also welcomed to highlight your point of view in the comment section.