[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: glib in kdesupport: yes or no?
From:       Havoc Pennington <hp () redhat ! com>
Date:       2003-03-10 16:17:05
[Download RAW message or body]

On Mon, Mar 10, 2003 at 03:47:00PM +0100, Scott Wheeler wrote: 
> The problem is -- at least from our perspective -- that the overwhelming 
> burden of "compromise" seems to fall on the KDE community.  From all of the 
> concrete examples that I've seen thus far "compromise" == "do things the 
> Gnome way".  I may have missed these things since I'm not subscribed to the 
> relevant lists, but could you give some example of Gnome compromising and 
> doing things the KDE way?

Sure, I'll just try to summarize everything I can think of:

 - Icon theme spec
 - Startup notification spec
 - Extended Window Manager Hints
 - Desktop entry spec
 - fontconfig/Xft
 - XEMBED
 - "system tray" protocol
 - thumbnail/preview system
 - menu system
 - D-BUS
 - XDND (drag-and-drop)
 - XSMP (session management)

Of those, icon themes, startup notification, desktop entries are
lifted pretty much wholesale from KDE, with minor changes. EWMH,
fontconfig, XEMBED, thumbnails, XDND, system tray, and XSMP predate
GNOME/KDE, or were done "from scratch." D-BUS is almost exactly like
DCOP, and nothing like CORBA. The menu system is more like the GNOME
way, but enough different that I have to rewrite the GNOME code
entirely.

Anyway, I think the most common historical pattern has been to do the
specs "from scratch" taking the best from each desktop, and often IMHO
we've had very good technical results from that.

> I don't think it's fair to expect the KDE community to link to the core 
> libraries of the Gnome project while saying that the Gnome project is not 
> willing to link to the core libraries of the KDE project.  I know, I know, 
> "tainted by the GPL" or whatever, but that just doesn't seem like the way 
> that things are supposed to work.

Again, I don't really mean to advocate linking to GLib (or discourage
linking to GLib). I'm just concerned with interoperability and I doubt
GLib or no GLib is the deciding factor.

Havoc
[prev in list] [next in list] [prev in thread] [next in thread]