Linked by Thom Holwerda on Wed 22nd Aug 2007 22:10 UTC, submitted by anonymous
Linux It is not too surprising that Ubuntu came in first in's 2007 Desktop Linux Market Survey, or that Firefox was the topmost browser by far. More interesting is that for the first time ever in the site's annual surveys, GNOME surpassed KDE among desktop environments (45% over 35%), with Xfce a solid third (8%).
Permalink for comment 265249
To read all comments associated with this story, please click here.
RE[4]: Gnome is back
by phoebus on Thu 23rd Aug 2007 15:30 UTC in reply to "RE[3]: Gnome is back"
Member since:

Hmmmm. Gnome indeed does incorporate non-gnome code and libs. But rarely, if ever, KDE technology.

On the other hand, KDE has been depending on Glib for years. While Gnome started projects to clone Amarok and Kalzium, didn't want to use Arts, cloned DCOP into dbus (which KDE promptly adopted), there are more examples.

Part of this phenomenon has to do with licensing and partly with the way Qt used to be set up. As to licensing, Gnome has a policy that its libraries be LGPL or some similar license (less restrictive than GPL). Any KDE libraries that linked to Qt would become, in effect, GPL for Gnome. As that would run counter to Gnome's usual library licensing scheme, linking to Qt (or KDE libraries which linked to Qt) was discouraged. DCOP, if I remember correctly, linked to Qt and serves as a good example.

Of course, the LGPL license of the Gnome platform libraries doesn't usually present a problem for KDE/Qt under their licenses. You can link to LGPL libraries without changing the license of your own libraries in turn.

As to Qt's structure up to and including Qt 3.x, my understanding is that there was no library separation between the graphical classes and the non-graphical classes. (I may be wrong about this. Please feel free to correct me. It is also my understanding that QT 4.x has this separation now.) So, if Gnome wanted to link to QString, for example, it would have been linking all of Qt's graphical toolkit classes as well. Clearly, that would present a problem for Gnome.

On the other hand, GLib contains non-graphical classes and functions. GTK+ was and is separated from GLib. (I.e. GTK+ links to GLib, but GLib doesn't link to GTK+.) So, KDE/Qt could link to an event loop in GLib without drawing in GTKButton from GTK+, for example.

So, practical considerations made it difficult for Gnome to make use of actual KDE/Qt code. On the other hand, Gnome folks started DBUS and patterned it after DCOP partly because the Gnome folk hoped it could be adopted by the KDE folk as well.

In fact, was founded in large part by Gnome folks who wanted to find a neutral ground to develop technologies *with* KDE to be used by both desktops. (I remember some of Havoc Pennington's early emails on both the Gnome and KDE lists about this.) Much of Gnome's energies for the past three or four years have gone into projects with the hope that the code could be used by *both* desktops. Some even when out of their way to avoid linking to GLib so that KDE more would be more interested in the libraries. That, I think, is the opposite of NIH.

However, as you say, both desktops have been guilty of NIH in the past, and both undoubtedly will be guilty of it in the future.


Reply Parent Score: 3