Biz & IT —

A first look at KDE 4.0 release candidate 2

The second release candidate of KDE 4 was issued earlier this week. Ars takes …

The KDE development community has been working on KDE 4, a major KDE revision that brings in numerous new technologies, and the official release is scheduled for next month. My colleague Troy has provided in-depth overviews of previous betas, but today we're going to take a look at the second KDE 4 release candidate, which was made available for download earlier this week.

For my tests, I used the KDE 4 RC 2 Live CD image proved by the KDE community. The Live CD is based on OpenSUSE and provides easy access to a complete KDE 4 environment.

Although the release candidate has many rough edges and is significantly lacking in polish, the underlying technologies are all in place and deliver some very impressive functionality. KDE 4 offers some unique architectural advantages over its predecessor, including a completely redesigned desktop and panel system called Plasma, an improved version of the KWin window manager with advanced compositing features, a new modular multimedia framework called Phonon, and a sophisticated hardware API called Solid.

KDE 4 uses a completely new visual style and icon set called Oxygen. The Oxygen widget theme uses a lot of subtle gradients, light shadows, round edges, and background highlighting. Generally, the Oxygen style manages to be attractive without becoming a distraction, but there are still some places where additional work is needed. This is most evident in a handful of preference dialogs where elements are cut off or not rendered correctly. In most of the major desktop applications, Oxygen looks nice. I was also impressed with the flexibility of Oxygen. The appearance preferences dialog gives users extensive control over the colors of specific elements. Oxygen looks great with both dark and light color schemes.

In current versions of KDE, Konqueror is both a web browser and a file manager. In KDE 4, the focus for Konqueror has shifted towards browsing, while Dolphin has become the default file manager. When I first looked at Dolphin back in April, I really liked what I saw. The version of Dolphin included in the release candidate still serves up all the same great features and adds a few more nice ones, like a new column view that is similar to the Mac OS X Finder. Dolphin is powerful, intuitive, and a pleasure to use.

I tested several other applications as well, like Amarok 2 and KWord 2, both of which are impressive despite some rough edges. KWord 2's somewhat unusual user interface is intriguing, but clearly requires more polish to be truly useful. KWord 2 pushes most of the formatting features into a vertical dock that runs along the side of the window, which seems practical for users with widescreen monitors. The Amarok 2 user interface has a lot of nice little aesthetic flourishes and is easily the most polished of the KDE 4 applications.

Currently, the most significant weaknesses in KDE 4 are in the Plasma desktop layer. The Plasma components used for the desktop and the panel are undercooked. One of the primary features of Plasma is support for desktop-embedded widgets—called plasmoids—that are similar in nature to SuperKaramba widgets, Windows Sidebar gadgets, or Mac OS X Dashboard widgets. I tested several of the plasmoids that ship with the release candidate, including a clock, battery meter, calculator, and dictionary. On two occasions, adding a plasmoid to the desktop caused the screen to go black and the computer to become unresponsive, requiring me to forcibly kill and restart Xorg in order to continue with my tests. The plasmoids themselves are also somewhat buggy.

The panel at the bottom of the screen, which is also provided by Plasma, includes a menu button, task list, and notification area. I was unable to find any way to configure the panel, which is significantly less functional than the panel in the current version of KDE.

The second KDE 4 release candidate illuminates the extent to which KDE 4 has matured since the earlier betas, but a massive infusion of debugging and polish is needed before the release next month. Heavy development on KDE 4 will obviously continue after the KDE 4.0 release, so whatever pieces are still missing are sure to be filled in eventually. Some critics point to the deficiencies of KDE 4 and argue that drastic reinvention of basic desktop components might not have been a good idea. After experiencing KDE 4 myself, I have to disagree.

Transitions are always hard, but when the dust settles, a clean break between versions and an opportunity to introduce some innovative new ideas should lead to a stronger user experience. After years of development, unnecessary cruft builds up and things tend to get disorganized. The KDE 4 transition, though it will definitely be rocky at first, gives developers the ability to cut away the cruft and reorganize code in a manner that makes the whole environment more future-proof and easier to maintain.

Evidence of the advantages might not be readily apparent to end users yet, but there are plenty of sweet improvements under the hood in KDE 4. Developer-oriented changes like the much-needed migration from Autotools to CMake, the shift from Qt 3 to Qt 4, or the move from DCOP to D-Bus, for instance, all offer very real advantages.

My experience with KDE 4 revealed a set of hairy, nasty warts that need to be resolved, but it also shone some light on some impressive improvements. Although I'm skeptical that all of the problems with the release candidate can be fixed in only one month, a rough first release seems a small price to pay for the significant long-term advantages offered by the transition.

Channel Ars Technica