What Is a “Desktop” in a Free Operating System? And How to Choose One?

Originally published on LiveJournal, 2.15.08

Unlike in Windows, OS X, and other proprietary operating systems, in many free operating systems, the “desktop” is an interchangeable piece of software. But, what is it, exactly? Isn’t the desktop, like, the whole point of an operating system?

It’s a matter of definition. In free operating systems, what is often defined as the “desktop” package really doesn’t do that much, and even without it your operating system would be perfectly usable, graphics and all. The name “desktop,” I think, is misleading. Only some of what it does is really desktop-related: 1) It proves you with the “desktop” space, which usually means a slate (with wallpaper) “underneath” your windows, where you can place files, folders and launcher icons (a.k.a. clutter). The upcoming KDE4 desktop will actually use a different concept, called Plasma, in which the things you put on the desktop are specially designed “plasmoids.” 2) It allows for a “start” menu on the desktop, and for related “accessory panels” on which you can add application launchers, clock applets, volume buttons, weather information, and other such life-or-death necessities. 3) It allows you to run screen-savers, to save your screen from... what, exactly? This hasn’t been necessary for over 20 years. But people like their screen-savers.

If you don’t care for these “desktop” things, great! You don’t have to run a desktop at all! The Enlightenment graphical shell, for example, implements a highly configurable right-click menu that does anything a desktop start menu does, and features certain windows that always appear on screen, that fill the role of both the “desktop” clutter and “accessory panels.” Enlightenment is not defined as a “desktop” package, but does what you need.

But, “desktops” also provide certain common facilities for applications that have nothing to do with the desktop, per se. This is where it gets a bit fuzzy, because some “desktops” provide more such facilities than others, and sometimes there is confusion as to what is officially part of the “desktop” or is an external facility. The reason for including these facilities in the “desktop” is that it allows you to configure all your applications from the central control panel, usually accessible via the “start” menu of the “desktop.” I think the better name for this type of functionality is “common facilities” rather than “desktop.” If you don’t run a “desktop,” you can still use these facilities, but you don’t have an integrated, central control panel to configure them.

Common facilities include things like a clipboard, drag-and-drop between applications, appearance/color theme/icon management, accessibility for the disabled, language and localization management, specialized input methods for wacky languages, a common help system and repository, facilities for embedding parts of an application in other applications (this was very popular in the 80s, with Microsoft’s OLE; unfortunately, this dated, confusing and ultimately pointless facility is still a central part of the KDE desktop; GNOME gives it lip-service via the Bonobo project), multimedia (common audio and video playback and recording) configuration, and some more obscure things that you’d rarely care about. Most annoyingly, in my eyes, is that font rendering is part of this “common facilities” package. The reason is that font rendering has to do with language support and localization. The result is an inconsistent look across “desktops” and, worse, inconsistent support for different languages.

If these “common facilities” are so similar to each other, then why don’t all “desktops” use the same set of facilities? The reason has to do with which programming libraries the application designer decided to use. Many are available to suit different requirements, both legally (different licensing) and for choice of programming language and development environment. Unfortunately, these libraries each have separate configuration options, so even such a simple thing as having the same color-scheme usable by applications using all libraries is currently impossible. There has to be a separate “control panel” for each set of applications. There is a welcome effort to make them common, and even separate from the “desktop,” or to create, at least, a common abstraction layer which makes the underlying implementation transparent for applications. It’s been progressing, but slowly. Things like drag-and-drop work (sometimes, and not so well) between applications designed on top of different sets of libraries.

The bottom line for now is that applications designed for one set of libraries are configurable with one control panel. Because each “desktop” comes with one such control panel, it effectively encourages one set of applications. You can freely run applications from sets foreign to your desktop; just don’t expect them to follow your configuration settings.

A somewhat limited advantage in specifically choosing applications from only one set is that some of the “common facilities” allow these applications to interact better (such as embedding, which I poo-poo above). There are occasional efforts to re-write an application for a different set of libraries, but these are huge projects that can take years of effort.

There are also differences between applications in each set that have nothing directly to do with the choice of programming libraries. For example, application designers sometimes stupidly assume that you’d prefer certain applications from certain sets. Thus, things like having your contact list shared between your email application and your instant messenger might not work if they are of different sets. There’s no technical limitation that causes this — it’s simply the assumption of the application designer, who decided not to support one particular application. Another non-technical, but important difference is that applications for each set tend to adopt a common human interface design. Some designs are better than others.

With all that in mind, the reasons to choose one “desktop” over another are only: 1) you happen to like the interface design and/or functionality of one set of applications over another, and, probably less important, 2) you happen to think that one “desktop”‘s start menu and panels are better than the others’. Or maybe the screen-savers are flashier.

I think GNOME human interface guidelines are the best, even better than OS X’s, from which they draw inspiration. They encourage a very little number of buttons and menus, sparse “settings” panels, and a clean, minimalistic, unified interface. It usually takes no more than a few minutes to know how to use a made-for-GNOME application. Whenever possible, I prefer to use the made-for-GNOME applications, which means it’s a good idea for me to run GNOME as my desktop, as it provides me with a control panel from which I can configure all of them together. However, if you like made-for-GNOME applications, you can also use the more minimalistic Xfce desktop, which uses the same set of libraries as GNOME, while providing far less desktop widgets, accessory panels, and other such things. Smaller means faster!

Some people prefer KDE’s more cluttered interface design, which encourages lots of bells and whistles, and plenty of icons, buttons and configuration panels. Some of these people say made-for-KDE applications are more “powerful.” Sometimes they really are, but not because of this inane preference for clutter. In any case, they run fine together with my GNOME desktop, except that they look and feel a bit differently because they are based on a different set of programming libraries, and follow different design guidelines.