Richard Stallman On KDE/GNOME Cooperation

Karma Sucks writes: "For the first time that I remember, RMS is encouraging collaboration between the GNOME and KDE projects. He offers a concrete idea: Unifying the themes between KDE and GNOME. Matthias Ettrich once went far enough to propose a default unified 'Linux' theme that both Qt and GTK+ could support."

Comments

Forget Themes: Make the Clipboards compatible

[rjamestaylor]

I use KDE but prefer Mozilla. I am *sick* of the incompatible clipboards that KDE/GTK use. As a matter of fact, I just complained to my co-worker about this and said, "This is why a monopoly is a good thing: someone to declare 'clipboard functions work this way or no way'". Damn I hate this.

Re:Forget Themes: Make the Clipboards compatible

[grungeKid]

Actually, the X has a fairly sophisticated clipboard
model, maybe a little bit too sophisticated. Hence it has traditionally been poorly understood and badly implemented in apps and toolkit.

Gnome does the Right Thing with respect to clipboards, while QT2/KDE2 uses a more limited clipboard model. The good news is that QT3 and thereby KDE3 will do the Right Think and therefore interoperate a lot better with Gnome (as well as properly written X apps such as XEmacs)

These comments are somewhat enlighening: http://dot.kde.org/1013076354/

Also read this for a backgrounder about clipboard and X: http://www.jwz.org/doc/x-cut-and-paste.html

Might be a good idea

[koh]

Flamewars like the Gnome/KDE one have always been a side-effect on free projects that have the same final purpose (and on free projects in general ;), but it's true that the rivality between developpers of such important components has to disappear. The idea is good, and given its originator it may have a considerable impact on future GUI development aims.

But I'm not quite sure if a compatible theme engine is the way to go... Many people still consider themed desktops as a waste of time and space, and sometimes you can find really awful things on themes.org ;)

Another direction may be the component object model itself. There has been, IIRC, at least one attempt to start an uniform interface between ORBIT and the KDE object model, and others may be under way.

IMHO, this would be a much better challenge for Gnome/KDE integrators, and provide a broader signal to the GUI community.

Microsoft has made COM first, then made XP skinnable. Of course, the Linux themes.org effect was not present then (IIRC), and maybe it was sheer luck. It worked for them anyway.

But I'll sure fancy some skinnable icons while drag/dropping objects between Gnome and KDE apps :]

Re:To Hell with RMS

[BlaisePascal]

That's not a fair reading, in my opinion.

RMS didn't like KDE because it was not "free" -- and in fact, in his opinion, it's position was threatening Free Software in general (it undermined the GPL, it took people away from developing Free alternatives, etc). So he argued against KDE, in favor of GNOME, a truely Free alternative.

KDE is now Free, in part because of serious amounts of lobbying by the Free Software Community, including RMS. KDE is no longer the bad guy, RMS no longer has a beef with KDE.

Now that the "Free KDE" battle is over, RMS is now saying "Um guys... we won -- ALL of us (KDE and GNOME) won, last year. It's time, past time, to stop sabre-rattling at each other". Since Qt became GPL-compatable, I haven't seen RMS stoking the GNOME v. KDE fires. Now he's trying to quench the GNOME v. KDE fires, because leaving them smouldering is bad for Free Software in general.

Better C++!

[Otter]

To my mind, the single most important thing RMS could do to help out KDE is to push for better C++ support in GNU. Advantages are:

• It will address what's generally felt to be KDE's biggest drawback.
• Do the same for Mozilla and every other C++ project, free and non-free, running on GNU systems.
• Point up the importance of the GNU contribution to what's generally referred to as Linux. (Not that I'm thrilled to see him getting more ammunition to pester us on that score, but it's not until I was cursing out the FSF for making C++ apps run so slow that I realized he's actually got a good point.)

Besides, it's something he's in a position to actually do, and which doesn't require anyone to sacrifice existing work.

(Poor guy -- he's like Alan Greenspan, where every public utterance is turned into a grand policy question.)

No reason for KDE/GNOME to depend on Qt/Gtk+

[qweqwe]

The main reason for the split, is the widget set dependence of GNOME and KDE. Until this issue is resolved, deeper interoperability issues won't likely be resolved.

You *should* be able to use Qt write a complete GNOME application that obeys GNOMEs theming rules, uses Bonobo, GConf and other GNOME technologies.

You *should* be able to use Gtk+ write a complete KDE application that obeys KDE's theming rules, uses KParts, DCOP and other KDE technologies.

Yes, it may be *easier* to write KDE applications with Qt, and GNOME applications with Gtk+, each desktop/platform shouldn't be *tied* to these widget sets.

That's not the way it works now. At the moment, I believe that GNOME's technologies (at least the one's in GNOME 2) are more decoupled from the widget set than KDE's. For instance, it's possible to write a Qt application that uses GConf2, Orbit2, GStreamer, and Bonobo2 without linking in any Gtk+. If you *really* work at it, you should also be able to integrate with GNOME's accessibility framework by hooking Qt components to the appropriate ATK+ options. That's a fair chunk of GNOME already. But there are many other GNOME features that Qt applications can't take advantage of.