This story originally appeared in LinuxWorld print edition in May 2003.

My comments in last week's column about KDE and Qt being superior to GNOME and GTK generated fewer gripes and flames than I expected. That's a good thing, because there's no reason for the comparison to be contentious. While I prefer Qt and KDE, I criticize GTK and GNOME hoping these environments will improve.

This week and next I will list my main concerns and complaints about GTK and GNOME. Jeff Waugh, a GTK/GNOME developer, agreed to review my columns and point out where he thinks I'm right, wrong, what is being addressed in future versions, what isn't, and why. If you contribute to or program with GTK, GNOME, Qt, and KDE, please send me your thoughts. I will select interesting opinions, condense them, and add my own reactions in a follow-up column. I understand that these aren't the only desktops, widget toolkits, and programming languages out there, but I would appreciate it if you'd confine your comments to GTK, GNOME, Qt, KDE, C and C++, otherwise I'll have far too much material for any follow-up. We can always address other tools and languages later.

Before I begin with my criticism, let me assure you I understand there are several different philosophies of application development. Some people prefer GTK not because it is the better tool kit, but because the approach makes more sense to them, because GTK is more granular than Qt, prefer C to C++, or another reason. I cannot address all of these factors, but I will try to take them into account wherever they matter. There are also legitimate licensing issues that will lead someone to prefer GTK to Qt, but I do not intend to address those, either.

Granularity

Those of you who like to micromanage every detail in an application are likely to prefer GNOME to KDE. I do not argue you're wrong for taking that approach. Nevertheless, I argue GNOME is wrong for failing to provide the coarse granularity one finds with KDE. There's no reason why GNOME has to eliminate its granular approach to fill in the gaps I'm talking about.

Take one of the complaints I voiced about Evolution's tool bars last week as an example. I'm used to right-clicking on a tool bar (or at least select an option from a menu) to get to a dialog where I can customize the tool bar. I cannot do that with Evolution or just about any other GNOME application, but I can with most KDE applications.

Before I delve into this matter, please understand that my point is not about tool bars, it is about the general differences in approach or perhaps differences in maturity between GNOME and KDE. The tool bar is simply an example to illustrate the point.

GNOME folks acknowledge that this feature is desirable. Here's a quote from the GNOME 2.0 Human Interface Guidelines (CVS draft):

"Allow users to configure toolbars to contain their own selection of commands, in whatever order they choose. If you do this, you should also provide an option to return the toolbars to their default configuration."

The KDE libraries include a class called KEditToolbar that makes it easy to add this capability to your applications. If you adhere to certain KDE standards, this class even makes it a breeze to manage the saved settings. That's one reason why most of the KDE applications I use not only offer the ability to customize the toolbar, the method for doing so is the same for all these applications.

But in spite of the fact that the GNOME guidelines suggest developers should allow users to configure toolbars, I couldn't find any similar API or class within GNOME or GTK that provides features similar to KEditToolbar. You may say that you prefer to micromanage tool bars with your own code, but KEditToolbar doesn't prevent you from doing that. You can code at the low-level in both KDE and GNOME, but the high-level option is not available within GNOME or GTK. You have to find a tool bar editing widget somewhere else, or micromanage the tool bar code yourself (at least as far as I can tell, based on searching the online documentation of the various APIs).

It is important to understand that my preference for the KDE approach is not just an issue of convenience for programmers. When you implement a human interface guideline through a standard class (or set of APIs) instead of just leaving everything up to the developer, you improve the chances that all applications based on these guidelines will have a consistent look and feel. Admittedly, sometimes you won't want a look and feel that is consistent with all other GNOME or KDE applications. That's the exception, however, and a high-level class or API doesn't prevent you from micromanaging the details if you want to.

Someone is sure to cry "bloat" at this point. In the case of something like KEditToolbar, it is only bloat for the user who never intends to customize a tool bar for any applications. Indeed, one could argue that the GNOME guidelines encourage people to implement this feature, therefore many people will do so. However, if you leave it up to individual programmers to implement these features, each application has its own separate code for managing tool bars. The fact that they're not sharing code is more likely to lead to bloat than a shared widget like KEditToolbar.

API Overload

Another problem I have with GNOME and GTK is that they are not really just GNOME and GTK. GNOME is difficult to pin down, since it may split into different directions in the near future. The catalyst here is Mono, the subset of the Microsoft .NET framework that Ximian is producing. I hope that will not lead to a split at all, but just another layer of development options.

Nevertheless, we can look at GTK to explain what I mean by my heading, "API Overload." GTK consists of GDK, GLib, GObject, Pango, GdkPixbuf, and more. I don't mean to mislead you into thinking you have to learn all these APIs. These libraries are layered such that GTK insulates you from most of the other libraries unless you want to access them directly. What bothers me is that the interdependence of separate layers makes GTK more fragile than it has to be. Fortunately, the fragility doesn't necessarily translate into crashes except when the underlying libraries are undergoing change. As a rule, I don't experience any more crashes with GTK applications than Qt or KDE applications. Nevertheless, be aware these interdependencies exist, and changes to lower layers do introduce the potential that applications will crash, malfunction, or simply not work. Even when my GTK applications work great, I often see error messages indicating problems that are likely the result of changes someone made to one of these libraries.

Flame-proof underwear

That's sufficient analysis to generate enough flameage to keep my bottom warm for at least a week or two, so I'll stop there for now. Next week I hope to address issues of maturity, language, and the GTK approach to themes.