Christopher B. Browne's Home Page

9. The KDE/GNOME Controversy

There has been a high degree of disagreement as to the respective merits of KDE and GNOME. This has generally centred one or more of the following issues:

The licensing terms of the Qt library stirred much controversy. When used for development of free software, Qt was treated by its authors ( TrollTech) as "free" software under the Qt Free Edition License. If, on the other hand, you wish to sell software based on Qt, the license required to allow you to do so costs approximately $1500 USD.

Recent changes to the licensing allow it to be used under the GPL, which pretty much nips that issue "in the bud," except for those that consider the GPL to be a horrible thing, with the LGPL (Lesser/Library GPL) being modestly less awful. You certainly can't satisfy all the people all of the time!

No doubt the fact that Qt uses C++ as the underlying language is also a piece of the percieved problem; for any given computer language one can readily find both vigorous proponents and opponents.

Further to this, until fairly recently, the quality of the freely available C++ compiler, G++, was rather poor. This has resulted in people having the attitude that C++ is a poor language choice.

The most direct "competitor," Gtk, is implemented using C which has the salutory effect that Gtk is almost trivially integratable with virtually any language, which is somewhat preferable.

These are all substantive issues that would cause some people to prefer Qt and others to prefer Gtk.

Unfortunately, there has been a lot of arguing over the moral superiority of KDE/GNOME. This often includes the following sorts of "arguments." Note that they get increasingly shrill and paranoid as one moves down the list. (And I have some parenthetic comments that I hope will not pour more gasoline onto the flames...)

For the most part, the people fanning the flames aren't actually working on code or otherwise contributing to the efforts, which means that the participation is not the slightest bit constructive.

And I feel that the efforts by both projects to rewrite all sorts of applications to use their respective GUI libraries are at best not terribly useful, and at worst actively unfriendly to the free software community.

Both projects unfortunately suffer from the problem that they represent solutions that are looking for problems rather than being direct solutions to problems.

Furthermore, both projects at this point break a number of the rules of The Unix Philosophy by pushing data into "binary objects," not revealing functionality via the use of filters.

Sometimes controversy isn't about the conflict between the two; there clearly are people not happy with how GNOME has been developing, as described in GNOME et all Rotting in Threes .

The following commentary suggests substantive reasoning to prefer not to use C++ to write GUI toolkits.


It really doesn't matter what language it was programmed in. It's still an OO toolkit. In order to have a language independent object model, the object model of the toolkit must not depend on the implementation language. C++ in particular is a bad language to choose for implementing a toolkit because its object model is officially undefined, by ISO.

Now, if you plan to program in C++ and only in C++, then this isn't an issue. The compiler knows the object model, so you don't have to. But if you want to have a project that's open to programmers of any language (e.g. Ada , Eiffel , Smalltalk , CLOS , Objective-C , Python , just to name some of the OO languages), then the last thing you want is a toolkit written in C++.

Actually, you can use a C++ toolkit from other languages, but it's extremely inefficient because you need to have double bindings, first from C++'s unspecified object model to a public object model, and then from the public object model to the other language's object model. I believe that some C++ toolkits have taken this route, and it works, and does allow more efficient C++ code, but less efficient code in any other language.

-- Chris Waters 

9.1. The Important Misunderstanding

There is a remarkably persistent set of "frequently asked questions" that demonstrate that there is a vast lack of understanding of what GNOME and KDE are, and that also demonstrate that the respective projects don't do a nearly good enough job of indicating what they really are providing. They also tend demonstrate that the questioners don't understand X very well; that's somewhat more forgiveable, to be sure...

Q: Can I run (some GNOME programs) with my favorite window manager? Isn't that going to conflict with the GNOME window manager?
Q: Why do they bother with these new window managers? I'm perfectly happy with BlackBox?
Q: I'm running GNOME as my window manager; how can I run thn> Konqueror web browser?
Q: But can I install GNOME and KDE at once?
Q: But which is better???

Q: Can I run (some GNOME programs) with my favorite window manager? Isn't that going to conflict with the GNOME window manager?

A: This betrays the lack of understanding that GNOME and KDE are not window managers.

GNOME and KDE are most legitimately looked at in two ways:

  • As a set of libraries providing services commonly needed for applications.

    X provides only the ability to display windows on the screen; adding in complex sorts of widgets requires additional libraries, which GNOME and KDE both provide.

    They go well beyond just widgets, providing other sorts of services that are often needed:

    • Configurable "look and feel," supported by what the environments call theme engines

    • Storage of application configuration data

    • Unified access to documentation, where a "help" menu item can spawn a documentation browser

    • Protocols to allow things like "drag and drop," where objects from one application may be passed on to another for processing

    • At a lower level, interprocess communications protocols, as with CORBA and DCOP and DBus.

  • As a set of applications that use the sorts of libraries and services described above.

None of the services or applications are of a sort that would prevent using different window managers or applications that use different GUI toolkits.

One of the major design parameters of X was for it to have the ability to simultaneously host applications that might use different sorts of user interfaces.

The downside to that is that you might well have a confusing set different GUIs being displayed on the same screen at the same time. It may be mentally somewhat "jarring"> if you had (for instance) Netscape Navigator, using Motif, in one window, a Tcl/Tk application beside it, a GNOME application, with still another set of application "decorations,"> a Windows application being emulated using WINE, with a Windows 3.1 style UI, perhaps along with LibreOffice, which has a somewhat Windows95-like UI, with the borders of all these windows being managed using Window Maker, with a NeXT-like UI.

The above scenario, while visually a bit "jarring," is certainly technically feasible, and I've had applications of all those sorts running on X concurrently.

Q: Why do they bother with these new window managers? I'm perfectly happy with BlackBox?

A: GNOME and KDE are not window managers.

GNOME and KDE are truly not window managers.

GNOME and KDE are really and truly not window managers.

KDE includes one (called kwm), and GNOME somewhat encourages the use of one called sawfish.

But they are emphatically not, not, not window managers.

They exist to provide application developers a rich set of services so that they may readily provide users with a rich set of powerful applications.

Window management is pretty small stuff compared to that.

Q: I'm running GNOME as my window manager; how can I run thn> Konqueror web browser?

A: The answer pretty much is "feel free;" add it to menu somewhere, or find a terminal and type in konqueror.

If you look back at the coexistence discussion, it's clear that all sorts of GUIs can happily coexist atop X. For GNOME or KDE to do something to prevent the other from coexisting would be entirely remarkable, and just cause to lay waste to the offender's project.

Q: But can I install GNOME and KDE at once?

A: Of course!

Both largely consist of a set of libraries. The libraries have different names, so they can happily coexist in /usr/lib or wherever else they may reside.

And they consist of a set of applications. Those applications have, again, different names, so they can also happily coexist in /usr/bin or /usr/X11R6/bin or whereever else they may get placed.

They're applications that request graphical services from X; since X was specifically designed as a multiplexing system that can provide simultaneous service to many X clients, there's no problem.

You might have a problem if your disk space or memory is highly limited, although as the prices of 256MB DIMMs fall, and as it gets increasingly difficult to obtain disk drives with less than 10GB of storage space, it becomes increasingly difficult for newcomers to have the "not enough room" problem.

Q: But which is better???

A: There are about as many answers as there are writers about the topic...

Contact me at