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 DesktopLinux.com'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%).
Thread beginning with comment 265243
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Gnome is back
by superstoned on Thu 23rd Aug 2007 15:03 UTC in reply to "RE[2]: Gnome is back"
superstoned
Member since:
2005-07-07

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.

Gnome fans don't like KDE apps, even if they have no alternative (K3B) they rather shiped Ubuntu without a decent CD burn app for years.

Rest assured, of course both sides are guilty of NIH one time or another. But it's far more prevalent on the Gnome side. KDE works on integrating in Gnome (Klearlooks, automatic button reordering), and integrating gnome apps (GTK-Qt theme, ld_preload hack, option to disable DPI detection), and Qt even supports the Glib event loop so you can use GTK in KDE apps and vice versa. Now give me a few examples from Gnome work in integrating (instead of rewriting) KDE apps in Gnome...

True, the developers are working together more and more on lower level libraries. It might be the community who rather tells ppl 'LINUX does not support 16bit RAW images' than admitting only KDE apps like Digikam, Gwenview and Krita can do that...

And it's not true KDE has 'very few external dependencies' -> http://www.kde.org/info/requirements/3.5.php

Yes, many are 'optional' which means you CAN compile the basic KDE apps without, but you'll lose functionality. take poppler, without it you can compile okular, but of course, it can't view PDF's...

Reply Parent Score: 10

RE[4]: Gnome is back
by phoebus on Thu 23rd Aug 2007 15:30 in reply to "RE[3]: Gnome is back"
phoebus Member since:
2006-12-24

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, freedesktop.org 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 freedesktop.org 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.

Cheers!

Reply Parent Score: 3

RE[5]: Gnome is back
by superstoned on Thu 23rd Aug 2007 15:35 in reply to "RE[4]: Gnome is back"
superstoned Member since:
2005-07-07

True, there are technical reasons for some of these things. But not all KDE technology depends on Qt - take the work by Jos van den Oever on indexing stuff [1]. or Arts, which I mentioned.

Anyway, the work going on on freedesktop.org is great, so let's be happy and hug ;-)

[1] http://www.kdedevelopers.org/node/2931

Reply Parent Score: 3

RE[5]: Gnome is back
by anda_skoa on Thu 23rd Aug 2007 18:33 in reply to "RE[4]: Gnome is back"
anda_skoa Member since:
2005-07-07

As to licensing, Gnome has a policy that its libraries be LGPL or some similar license (less restrictive than GPL)


Same for KDE see (3) in this document
http://techbase.kde.org/Policies/Licensing_Policy

DCOP, if I remember correctly, linked to Qt and serves as a good example.


DCOP is actually a bad example, since it is a communication protocol and can therefore be implemented with basically any kind of technology that can operate on raw data.

Basically like the Mono and Java implementations of D-Bus are directly implementing the "wire" protocol instead of mapping to the base library.

Reply Parent Score: 3

RE[4]: Gnome is back
by Hiev on Thu 23rd Aug 2007 15:50 in reply to "RE[3]: Gnome is back"
Hiev Member since:
2005-09-27

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.

Those are half lies and half trues, GNOME didn't clone anything, if a project do not meet GNOME guidelines then of course they will but Amarok is as old as the GNOME options, now, KDE apps. are to dependent of Qt and Qt is GPL and since GPL can take code from LGPL easily LGPL can't take code from GPL, now, the only compatible LGPL are the KDE libraries, wich are to tied to the all KDE libs, that's not very atractive at least you are creating a KDE application.

And you give to much credit to dcop, dcop was to dependend of KDE and Qt and that was out of the question for GNOME, and dcop was a mess by itself in the code point of view, saying that dbus is a clone of dcop is just a fallacity, dbus is way ahead of dcop, and no, is not real that dbus borrowed a lot from dcop, because dbus is clean, dcop is not, that was made up by KDE developers.


Gnome fans don't like KDE apps, even if they have no alternative (K3B) they rather shiped Ubuntu without a decent CD burn app for years.

K3B is nice but it makes to much for the basic needs of the users, till now I haven't found any killer feature K3B has that I need.

Rest assured, of course both sides are guilty of NIH one time or another. But it's far more prevalent on the Gnome side. KDE works on integrating in Gnome (Klearlooks, automatic button reordering), and integrating gnome apps (GTK-Qt theme, ld_preload hack, option to disable DPI detection), and Qt even supports the Glib event loop so you can use GTK in KDE apps and vice versa. Now give me a few examples from Gnome work in integrating (instead of rewriting) KDE apps in Gnome...

KDE dind't do all that, all comes with the benefit of using Qt as a toolkit, the Glib Event loop, the button order, the Klearlooks theme, even the dbus libs come with Qt, all was made by TrollTech for Qt, not by KDE developers, the only credit KDE developers get is the Qt-GTK theme engine.


True, the developers are working together more and more on lower level libraries. It might be the community who rather tells ppl 'LINUX does not support 16bit RAW images' than admitting only KDE apps like Digikam, Gwenview and Krita can do that...

16 bits, CMYK ain't nothing than more fallacities to show off, those are good to have but certaintly not necessary.

I really hate to be involded in this GNOME vs KDE war but I really can't stand the trolling and half trues of KDE members.

Edited 2007-08-23 16:10

Reply Parent Score: 0

RE[5]: Gnome is back
by anda_skoa on Thu 23rd Aug 2007 18:38 in reply to "RE[4]: Gnome is back"
anda_skoa Member since:
2005-07-07

even the dbus libs come with Qt, all was made by TrollTech for Qt, not by KDE developers


I am afraid Thiago will not like hearing that he is no longer a KDE developer.

And I am afraid I do not like to read that I am no longer a KDE developer, just because I created Qt3 bindings for D-Bus.

Cruel world, this is.

Reply Parent Score: 5

RE[5]: Gnome is back
by superstoned on Fri 24th Aug 2007 09:58 in reply to "RE[4]: Gnome is back"
superstoned Member since:
2005-07-07

I'd go with Anda here, he makes a valid point. Technically, Qt and KDE are seperate, but in practice, they are as tied to each other as GTK and Gnome.

He makes a point about the DCOP thing as well, I guess you read that, so I don't have to reply on that as well.

The K3B thing was mostly a thing of the past, when Gnome/GKT didn't have a half-decent cd burn app (and I'm not only talking about features like burning a .iso file, but also about working on and with every cd burn device out there). Now there are G apps that are good enough, and if you are happy with basic and (believe you) don't need anything else, you can do without K3B.

Anyway, lovely comment - 'half lies half trues'. I did exaggerate, but not lie - it's more true than you think (and say). Though, I agree, truth is a difficult thing and there's a thin line between exaggerating and lying. So I guess it depends on one's world view.

Reply Parent Score: 4