(LinuxWorld) — Judging from the comments about my article last week, many readers seem to have missed the point. I used installation experience to draw attention to both the negative and positive consequences of the different designs in GNOME and KDE.

What should have tipped off most readers is the fact that the very things I complained about — the GNOME approach of scattering of configuration files, the imitation of the Windows registry, the inconsistency of the user interface, the lack of features in the user interface, the lack of features in Nautilus, etc. — have nothing to do with GNOME on Debian. Unless Debian alone has a special "crippled design" version of GNOME 2.2 that is based on an entirely different framework than GNOME 2.2 for every other distribution, then the issues I raised apply whether your installation of GNOME goes perfectly or not.

Since so many people seem to have missed the point, allow me to elaborate on one of the core issues this week. One of my readers identified the problem with GNOME best when he said that GNOME is a Franken-GUI, cobbled together from disparate pieces.

GNOME fans have been reciting two battle slogans for years:

1. "KDE may have the best desktop, but all the best applications are written for GNOME."
2. "You have to use C++ to write to KDE, but I can use any language to write for GNOME."

I'm not going to waste time debunking the latter claim, because you don't hear it very often anymore. Plenty of alternate language-bindings have emerged for Qt and KDE, so nobody is limited to writing in C++. Most GNOME fans know this by now, but I have a good reason for mentioning this second argument anyway; it has a subtle connection to the reasons why you're about to see the first argument vanish.

The question has always been: "If GNOME is such a tangled mess, why are the applications so much better than the ones for KDE?" Back in June of 2002, I admitted that many KDE applications were essentially brain-dead in important respects, but I predicted KDE applications would catch up and overtake the equivalent GNOME and GTK applications (see "Why KDE applications have a bright desktop future," in Resources below).

I thought this would take more than a year to unfold, but the evidence that my prediction is on target is already mounting. Most of the features that were missing, to KDE's shame, are now present: tabbed windows in the browser, misspelled words are highlighted as you type in the word processor, and so on. I still have some items left on my wish list, but that list is shrinking very quickly.

The visual evidence

As I mentioned in my last article, one of the striking differences between GNOME and KDE is the lack of consistency in GNOME compared to the near-universal consistency in KDE. KDE has consistent dialogs for reconfiguring key bindings and customizing your toolbar. There's no point in comparing the consistency of the dialogs to GNOME, because these features are not part of the GNOME framework. You have to add them yourself. Therefore, many applications don't even provide these options, and the ones that do aren't consistent with others that do.

In addition, those elements of KDE that are common in both KDE and GNOME are not only more consistent, but they tend to be more feature-rich in KDE. Here is a brief look at the differences in the file pickers:

Editor's note: The above image is reduced in size to allow it to display on this page. Click on this image to see the original.

The file picker in KDE lets you add quick jumps to directories as icons in the list on the left (see picture above). You can specify that these icons will appear for all applications, or just the one you are using. You can also add bookmarks to the file picker that will appear in all applications. The KDE picker also lets you navigate through the directories the way a browser does. You can go up one level, or back to the last directory you were in, and forward, too. There is a preview pane, where we can see Uncle Verde Fester. Not shown: You can split the pane into two, where directories appear on the left and files on the right. You can also view hidden files, create directories, rename, and delete files.

The GTK/GNOME version of the file-picker lets you pick a file, delete a file and create a new directory. It has that ancient, Macintosh-like pull-down list that includes the directories above the one you're in.

The true advantage

If you miss this next point, you will never understand why the above comparison is so important. It is not primarily about features. Yes, the KDE file-picker slam-dunks the GTK equivalent in terms of usability and consistency, which is what makes it so attractive. But the most-important difference between the two is what goes on behind the scenes. The reason the file-picker is so easy, feature-rich and consistent is that it is a standard part of a cohesive, maturing framework.

The object in question is called KFileDialog. This is part of the KDE framework, so unless you deliberately step outside of the KDE framework when you write your application, you will use KFileDialog whenever you need a user to select a file. As KFileDialog improves, your application automatically inherits the improvements. That's the point. As anything in the framework improves, so do the applications. As a result, programmers and their applications stay consistent and inherit the improvements with little or no effort on their part.

The KParts controversy

In terms of a consistent library of components, KDE offers more than KFileDialog. It also has KParts. KParts are components that are the rough equivalent of ActiveX (also known as COM a.d.a OLE) components that you can embed within frames and other components. For example, KParts lets you embed a spreadsheet into a document.

One of the nicest things about KParts is how easy it is to use from a programmer's perspective. I strongly suggest you read a short tutorial on the topic from freehackers.org (see Resources below for a link). It demonstrates just how easily one can discover and embed any KPart into an application with just a few lines of code.

The KDE developers were criticized for moving to KParts, and I was one of the critics because I have always been a big fan of CORBA. Thanks to GNOME, I see things very differently now... and that leads us into the next section.

The different faces of GNOME

While KDE is filling in all the gaps, and while KDE applications catch up with and overtake the GTK/GNOME equivalents, the same holes in GTK/GNOME remain. New holes are appearing, as well. Read my lips: no new file-pickers. No consistent interface-components. The full-featured sawfish window manager has been ripped out, and a weaker-featured version has replaced it. Nautilus, the file manager, is basically stripped down to a bare minimum of features.

One of GNOME's biggest problems is that it can't make up its mind regarding what it is. GNOME started out as a framework, a panel, the Enlightenment window manager and GMC, which is the graphical version of Midnight Commander. At some point, Enlightenment was replaced with Sawfish as the default window manager. The incredibly buggy and slow GMC was eventually replaced with what is now Nautilus.

Now the default window manager is no longer Sawfish, it's Metacity. Nautilus has gone through major revisions, as have the panel and control center. Meanwhile, a whole new Windows-registry-like system was added. Applications, on the other hand, are still using the old GTK as well as the new.

Some people regard the independence of window manager, file manager and toolkit as GNOME's major strength. They aren't considering how much the flexibility costs GNOME in terms of combining a rich feature-set with consistency and usability. Why the lack of features in the window manager and file manager and blatant inconsistencies in the applications don't tip them off is a question I can't answer.

So if the window manager, file manager et al aren't GNOME, what is the heart of GNOME, anyway? A panel?

That certainly wasn't the original plan. GNOME stands for GNU Network Object Model Environment. The reason the GNOME designers chose CORBA as the object model was reflected in the part of the name that stood for "network object model".

CORBA is a distributed-object framework that lets you create disparate components that discover each other and interoperate over a network. CORBA can also be used in other ways, but its primary purpose was to be a foundation for distributed objects. In other words, CORBA not only contains all the necessary features to build interacting components that discover one another, but also the features one needs for network-security issues. Put yet another way, CORBA is Web-services done right — it simply doesn't do it over port 80.

CORBA derailed

So where are all the distributed-network objects in GNOME? It was supposed to be the GNU Network Object Model Environment, wasn't it? The potential is there, but it has never been exploited. What happened? The GNOME page on Bonobo, one of the pieces of GNOME's CORBA architecture, doesn't even include the words "distributed" or "network." It does, however, say this: "One added benefit of basing the component system on top of CORBA is that programs written in any language can use components written in any other language."

Sound familiar?

2. "You have to use C++ to write to KDE, but I can use any language to write for GNOME."

While the GNOME documentation calls it an "added benefit," I would argue that GNOME was hijacked somewhere along the line. The language-neutrality of Bonobo not only became its main benefit, it also became its very reason to exist. No wonder Miguel de Icaza, the man behind Bonobo, went ape over Microsoft .Net! It's the language-neutrality holy grail! Indeed, here is a revealing quote from an article published on userland.com where Miguel de Icaza lays out the rationale for Mono:

My interest in .NET comes from the attempts that we have made before in the GNOME project to achieve some of the things .NET does:

• APIs that are exposed to multiple languages.
• Cross-language integration.
• Contract/interface based programming.

GNOME won't necessarily go wherever Miguel goes. But it if does, then Mono's common-language interface will replace Bonobo, and the only thing left of GNOME will be the panel.

Whichever way the future turns out, one thing is clear: the GNOME architecture has been obsessed with supporting multiple languages while ignoring the things that could have made GNOME unbeatable. It ignored the richness and consistency of the foundational component framework and the one benefit of CORBA it could have exploited to make GNOME far better than any other desktop environment. GNOME could have remembered the word "network" in its name and used the distributed-network component design of CORBA to make GNOME uniquely and amazingly great.

Worst of all, by getting sidetracked and making language-neutrality the highest priority, GNOME has been relegated to a fate of disintegrating and reintegrating in a seemingly endless effort to find some decent combination of file managers, window managers, panels and components. Along the way, features seem to be disappearing more often than they are maturing. The coherence and consistency that would have resulted from a single-component framework never coalesced, because that approach would have violated the desire to wrap everything in GNOME around a language-neutral model such as Bonobo.

So, what is GNOME? This question certainly doesn't have the answer "GNU Network Object Model Environment." GNOME never exploited the features of CORBA that make it great. GNOME never made distributed objects a goal. It ignored usability and a rich feature-set in its component framework in favor of the ability to support multiple languages, multiple window managers and multiple file managers. GNOME has become a Language Agnostic Morphable Environment. GNOME has become LAME.

Meanwhile, the KDE architecture has quietly been accumulating a rich library of consistent objects for use by application programmers. It has also added language-bindings to make those objects available to languages other than C++. In the end, KDE is delivering a better version of what GNOME was hijacked into making its goal: a great component framework that you can write to in multiple languages. GNOME's higher purpose was forgotten somewhere along the line, after which it degenerated into a LAME Franken-GUI.