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:
KDE uses once-proprietary Qt GUI toolkit.
"Evil licensing."
This is now an utter fallacy, as Qt has become available under the GPL.
(Of course, for those that are anti-fans of the GPL, neither GNOME nor KDE can be much good...
KDE is all in C++, and C++ is obviously icky. Or Gnome is based on a bunch of C-based libraries, and C is obviously inferior to C++.
Well... C++ does have considerable demerits if you wish the resultant system to be relatively language-neutral, and there is no standard ABI for it.
And there are some fascinating comments on this on the Gnome side; one of the main developers of the GTK and ORBit libraries has commented:
Don't use C; In my opinion, C is a library programming language not an app programming language. | ||
| --Owen Taylor | ||
KDE folk decided that CORBA was "much too slow" to use, and so use a local IPC scheme called DCOP, whereas GNOME folk have built their own ORB, ORBit.
What is richly entertaining is that both groups are considering integrating in SOAP or XMLRPC , which push XML "over the wire"> and then have to parse it, which is vastly slower than CORBA ever was...
More recently, there has been a migration of both systems to use DBus ...
There has been some "personality bashing" back and forth on occasion.
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...)
KDE is a good choice because it looks quite a lot like Windows 95, which new users will find "friendly."
(They may think it friendly; I don't care for it myself, but don't feel real strongly about it...)
KDE is garbage produced by evil Microsoft-lovers because it looks like Windows 95...
(Which has very little merit.)
KDE is more functional, whereas GNOME is just vaporware.
(And it has about a year's lead, which could lead to the argument that it should have a greater lead than it has. I'd much rather argue this based on the status of both systems a year from now.)
Red Hat Software are the "spawn of the devil" and are trying to destroy Linux and turn it into evil commercial software by their support of GNOME and their lack of support of KDE even though "most users want KDE."
(Apparently Red Hat didn't feel like supporting Troll Tech's then-proprietary software. That is their right. And I'd like to see the survey that establishes that "most" people want to use KDE. I'm not 100 sure I want to have either KDE or GNOME cluttering up memory/disk/screen space until there is some compelling value to it...)
Troll Tech are the "spawn of the devil" and are trying to take over Linux and turn it into evil commercial software because Qt does not use the GPL.
(Which is about as silly as the notion that Red Hat is trying to "take over" Linux. Both notions have some merit; just not much merit...)
(Furthermore, Qt now does use the GPL, so this one's no longer valid.)
There's a conspiracy against KDE because some (periodical/conference) had an (article/talk) on GNOME and none on KDE. Obviously they're trying to exclude and marginalize KDE at the behest of the evil Microsoft-like Red Hat Software.
(Perhaps the GNOME people have been quicker off the mark to get papers in than KDE people. The Linux Expo "Call for Papers" in 1997 was quite well publicized, which argues against conspiracy, and for the notion that KDE people were too busy doing other things to realize the requirements for presenting talks. Perhaps Linux Journal is quick to listen to Red Hat due to the advertising dollars that are exchanged and Troll Tech is not so well listened-to because they don't control any LJ advertising dollars. Which could be repaired by some advertising dollars. Likely KDE people have merely been victims of poor timing. Or perhaps it was the gunman on the grassy knoll...)
Some of these KDE people are such "scumbags" that they have declared intentions to steal the source code to GIMP and rewrite it with a "K" on the front.
(And as GIMP is GPLed, is it not legitimate for people to take the source code and modify it under the auspices of the GPL? It seems to me to be a really stupid idea to rewrite GIMP to use another GUI library when it and Gtk were specifically written to support one another; if some people feel like wasting time on such a task, at least it's likely to promote increased interoperability so that people can more readily take software written using a free GUI toolkit and retarget it to a proprietary toolkit. The benefits of that should be obvious...)
(In any case, it appears merely that someone spent a day or two doing "proof of concept" work to show that you could redeploy GIMP using Qt. Actually making it work usefully would require substantially more effort...)
(Beyond that, it annoys me that both projects seem feel the need to recreate all sorts of applications just so that they can use their GUI toolkit. I don't think that's the important part of the projects; the important aspect is that of interapplication communications, which should not have anything inherently to do with what GUI toolkit is used. Give the world a "GNOME Toolkit" or a "KDE Toolkit" that allows people to attach wrappers for what GUI library support might prove necessary.)
My lack of esteem for KDE comes from the consideration that it seems primarily dedicated to providing a "pretty GUI;" in contrast, GNOME treats this as secondary to the issue of exposing powerful interface tools such as CORBA and scripting tools like Guile. Actually, as of 2006, this doesn't seem to be true anymore; arguably there may have always been limited truth to this...
I also am not keen on KDE applications in that they have the (Mac-like) habit of taking over the top bit of the screen to have application menus. I frequently run window managers that have "virtual desktop" capabilities that seem to conflict with this; I either find that the KDE app "takes over" the top of every screen, or the wrong one. I'd rather that they kept inside their own windows.
I occasionally use a Mac ; I don't think my Unix apps forcibly have to take on an identical user interface.
Some recent "flaming" of GNOME and Red Hat has come from people that seem to have particular hatred (and I don't think I'm misstating it as "hatred") towards the FSF.
The argument presented in this case is something like:
Linux can't succeed until it has "proper" commercial support
The FSF are a bunch of "commies."
I am not exaggerating; the following line is a direct quote:
"GNU=commies=socialists=bonzi tree mentality" --
<bigrex@home.com> Bob Nixon
I can't but ridicule the mentality that confuses "Ponzi Scheme" and "Bonsai tree," whilst associating it with the FSF, communism, and Japanese miniature trees.
It makes me want to consider that according to my own private definition, he's an elm tree.
Keep in mind that Mr. Ponzi only ever operated in nations that at least call themselves capitalist...
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. | ||
-- <cwaters@systems.dhl.com> Chris
Waters | ||
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?
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.
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.
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.