some questions regarding KDE vs. GNOME cooperations.

Kevin Krammer kevin.krammer at
Mon Mar 10 22:04:50 GMT 2003

On Montag, 10. März 2003 08:21, Ali Akcaagac wrote:
> Hello, I have found some writings regarding KDE and GNOME the past
> couple of weeks which I find highly irritating, maybe because I have
> problems understanding all of them correctly. Therefore I would like to
> ask for some clearing comments on my following topics.

I can only provide my view of the things I jave been reading.

> 1) There are a bunch of writings on the GNOME, KDE and Freedesktop
> Mailinglists about changing the default KDE Configuration in favour of
> GConf (Windows Registry and written by GNOME) as new default
> Configuration. What exactly is up with that ? Some KDE developers (At
> least I think they are) write it will become part of KDE really soon
> and some write it will not happen. I can't show any resources with
> direct links on this now but I'm sure that many of you read and heard
> similar things.

Haven't read about this yet.
I think that if GConf is superior to the current system technology wise, 
it might be used in KDE4.
Please also note that KDE4 is not very near future :)

> 2) There are a bunch of writings about KDE trying to adopt GStreamer
> (written by GNOME) for KDE 4.0 as default Multimedia Framework and
> getting rid of ARTS. What's up with that since GStreamer depends on
> GLib.

There is a discussion about alternatives to the current system.
Also for KDE4.
My understandig of this is that currently no available system addresses 
all needs and there are very different needs.
If I understood stw (the aRTs maintainer) correctly, he aims at providing 
a way to make KDE more independ of the actualy sound system used.
So that it would be possible to not use arts if its capabilities are not 

The glib "problem" is IMHO not as big as mails from some people suggest.
Most KDE developers will only work with a highlevel KDE API and never have 
to use gplib directly.
glib would only needed if creating new codec plugins and stuff like that, 
which is usually written in C anyways, so using glib can't be a problem 
from those developers.

> 3) There are a bunch of writings about KDE reducing configurations
> because GNOME did it with their 2.x release. And some replies from KDE
> people were that this won't happen. Instead removing Configuration
> options, these options should get arranged better. And now on
> there is a writing
> where the leading KDE
> developer team and the leading GNOME developer team seem to have found
> a consens that indeed heavy configurability hurt and that something has
> to be done. Does this mean that KDE is removing the same way as GNOME
> did ? How will new arrangement of Options reduce complexity ?

AFAIK the idea is to reduce the default number of options available in 
control center but to have some kind of "extended config center" for 
people who like to control more details of their environment.

Like tweakUI on Windows, but as a KDE standard tool.

> 4) A bunch of KDE developers found their way to the GNOME development
> lists and they are talking about adopting DBus (written by GNOME) for
> KDE 4.0. Besides this some other aspects have been touched there such
> as GStreamer, adapting Glib (without GObjects) and some other stuff
> from GNOME.

The DBus thing seems to be very low level, below the current level of 
desktop environments.

I think it aims at providing a system wide signalling service, much like 
DCOP is a desktop wide system.

The things I have read so far sound very promising.

This would allow to have applications and deskopt environments react on 
system state changes without checking all system themselves.
Like "CD inserted" or "USB device connected" or "modem connection dropped"

> a) KDE adapting all stuff from GNOME,
> b) KDE is cooperating with GNOME on one HIG (button re-order),

So far they only merged the two HIG into one document so they can find 
part which are equal or similar.

I don't think any of the two projects will switch to the others HIG 
anytime soon.


Kevin Krammer <kevin.krammer at>
Developer at the Kmud Project
This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list