A tale of two desktops

There’s a split in the Linux world that transcends distributions: the divide between the GNOME and KDE desktops. That continues even as the two halves grow closer to each other through shared technologies. I’m sure my allegiances have been made clear by the many GNOME desktop screenshots that I’ve filled this column with over the years, but I certainly don’t discount the efforts of the KDE project. In fact, I recently thought about just how far they’ve both come since their inceptions, and realised that for the many Linux users that have come to the platform in more recent years, the reasoning behind having two major desktops may not be at all clear - it’s just something that’s always been. Of course, it hasn’t always been this way.

Wave the page to make it look like a flashback
It certainly doesn’t seem like the modern Linux desktop has been more than 10 years in the making, but it’s true: work on KDE started way back in 1996. The Linux desktop back then consisted mainly of components not written on Linux systems, but rather ported from the X desktops of proprietary UNIX systems.

X dates back to the early 80s, and in 1996 that was still quite obvious. With no modern, powerful GUI toolkits in existence, developers often had to take considerable liberties with the toolkits of the day, or end up rolling their own. Only a proprietary desktop called CDE approached the consistency and ease of use of Windows 95 or Mac OS, but it was a poor substitute at best.

KDE started with a single Usenet post by a young developer called Matthias Ettrich, pointing out the inadequacies of the existing Linux desktop and calling for volunteers to work on a replacement. His plan was ambitious, but it already had many key details in place: the new desktop would include a panel, a file manager, a HTML-based help system, and utilities like a terminal and a mail client. Most importantly, the new desktop would be written in C++, using Qt, a powerful and mature new GUI toolkit.

Qt was not regarded as open-source at the time -- its code was available free of charge, but under a restrictive licence that forbade commercial use. Many thought that this could prove a problem in the long run, but KDE’s future was by no means certain, and the developers reasoned that they could deal with the licencing issues if and when KDE succeeded.

Of course, KDE did succeed, and by 1997 the licencing issues had already come back to haunt them. Beyond words of warning and worry, there was more practical fallout, including the exclusion of KDE from Red Hat Linux, which put KDE beyond the reach of many of the less experienced users it hoped to attract.

Partly in response to the Qt woes, in 1997, Miguel de Icaza and Federico Mena founded the GNOME project. Mena was working on early versions of The GIMP, and realised that GTK, the C-based GUI toolkit developed as part of the GIMP, could be adapted to handle general desktop duties. GNOME gained many supporters, including Red Hat, which fast-tracked development to make GNOME 1.0 the default desktop in Red Hat 6.0.

With its development head-start, and the boost provided by the mature Qt toolkit, KDE reached version 1.0 in July 1998, ahead of GNOME 1.0 in March 1999. Around this time, Qt developers Trolltech announced that the upcoming 2.0 version of Qt would be released under the Q Public Licence (QPL), a true open-source licence. Eventually the code was also licenced under the GPL, nullifying concerns about Qt licencing, at least in regard to development of open-source projects like KDE.

By that time, though, GNOME was already well established, and it was clear that its developers weren’t going to abandon their hard work just because Qt’s licence had changed. Besides, in building GNOME they’d created their own unique vision for the perfect Linux desktop, often differing from the plans of the KDE developers. For better or worse, Linux would have two major desktops.

A tale of two desktops
Both GNOME and KDE have gone from strength to strength since those early days, and both today are great desktops, though they remain quite distinct projects. There are many similarities of course, and this is to be expected: neither really diverges from the basic desktop concepts that also underpin Windows and Mac OS, since those concepts seem to work well, and they’re certainly familiar to existing computer users.

In terms of design and intent, the most fundamental difference between GNOME and KDE is in the way they approach usability. The GNOME project takes a very proactive, and sometimes controversial approach, with a detailed set of human interface guidelines (usually called the “HIG”) that guide application design. Among other things, the HIG recommends that applications use sensible default values for all configuration options, and that those options are kept to a reasonable minimum to avoid confusion.

When the HIG was introduced in GNOME 2.0, its influence was immediately apparent: many of GNOME 1.4’s less-useful options and features were simply missing. This certainly reduced complexity, but many users argued that the developers went too far. As new versions followed though, some of the more sensible options were added back without sacrificing simplicity, and the users started to see the wisdom of the new GNOME.

The KDE approach to usability is less hard-line than GNOME’s, though the developers take it no less seriously. KDE remains incredibly configurable, and for many users this is a great boon: rather than having the desktop dictate a user’s behaviour, a power user can jump right in and customise the desktop to suit their needs.

KDE has often looked to technical solutions to usability issues. For instance, KDE 2.0 introduced a number of powerful new widgets, such as its toolbar, which presents rows or columns of icons in a window. Because the toolbar was both powerful and easy to use, it was rapidly adopted by developers, improving consistency across the desktop. KDE also features a wizard that runs on each new installation or upgrade, which allows the user to broadly reconfigure defaults across the desktop with just a few clicks.

In many ways, KDE embodies what people expect from Linux: superficially, it’s similar enough to Windows to make new users quickly feel at home, but with that “power user” edge provided by its remarkable configurability. Conversely, GNOME tends to do things the “right” way, following research in to user interface best practices, even if this requires an initial adjustment for the user. This often makes it more superficially similar to Mac OS.

The different file management interfaces provide a great example. In GNOME, the file manager uses a “spatial” metaphor, opening each folder in it’s own small, simple window by default, similar to Mac OS 9. KDE however follows the browser metaphor and mixed file and web browsing of Windows 98 and later. GNOME uses spatial file management because the developers feel strongly that it’s the right way to do it, even though it’s initially off-putting for users coming from a Windows background. You can easily switch to browser-style file management though, and in fact Ubuntu does so by default in its GNOME installation.

Which desktop gets it right? Well, I don’t think I’m to say except when it comes to my own use. For what it’s worth, I greatly value the simplicity and cleanliness of GNOME, and that’s why I use it on my desktop. I find that it keeps out of my way, letting me get on with my job without having to spend any unnecessary time interacting with the desktop itself, rather than the tools I’m using.

If you prefer KDE though, you’re certainly not without company: Linus Torvalds himself recommends KDE, and has criticised GNOME of treating its users as idiots. A recent spat saw GNOME developers challenge Linus to put his code where his mouth is, and he was quick to supply patches to fix a configuration inadequacy in Metacity, the GNOME window manager. His patches were later accepted with slight modifications.

Converging futures?
I must admit that I was hoping to present you with a glimpse of the future this month: a look at the upcoming KDE 4. Unfortunately, when I installed the latest pre-release, 3.80.3, I found that there wasn’t lot to look at yet. A lot of work is going on under the hood to move KDE to the new Qt 4, which promises to improve performance, and to introduce new multimedia and hardware management frameworks. The shiny new stuff, codenamed Plasma, promises integrate the desktop and panel with SuperKaramba, KDE’s alternative to Apple’s Dashboard. Plasma is still in heavy development though, and is absent from the pre-releases, so the 3.80.3 pre-release still looks much like KDE 3.5.

Surprisingly, there’s no grand GNOME 3.0 plan, because the developers don’t yet see the need for one. GNOME 2 continues to improve with each release, and so far there have been no fundamental issues identified that would require a major overhaul to fix. For now, the plan is to continue to incrementally improve GNOME 2, improving performance and adding new features and applications, like Seahorse, a crypto management tool scheduled for inclusion in GNOME 2.18. More fundamentally, many underlying GUI features are being moved from GNOME in to GTK, such as printing support. The long-term goal is to remove the distinction between GTK apps and GNOME apps - instead, all GTK apps will benefit from GNOME-specific features when running on a GNOME desktop.

Arguably the most important feature that both desktops are working towards is consistency. The freedesktop.org project is working hard on specifications and projects that can be used by both desktops. This not only makes the user experience more consistent across desktops, but it also helps developers build applications that feel more at home regardless of the user’s choice of desktop. It also lets the desktops pool resources rather than writing their own implementations of various technologies.

Many smaller steps toward consistency have already been made by both GNOME and KDE. KDE 4 should also see the adoption of freedesktop.org projects like the GStreamer multimedia framework and D-Bus inter-process messaging framework. Developments like this should continue to improve the consistency of the Linux desktop in to the future.