glib dependancy in KDE3.x

Philippe Fremy phil at
Thu Mar 6 16:56:34 GMT 2003


I remind or inform you that glib will also be a dependancy for the  
accessibility module, planned to be implemented as a plugin. So we have 
actually  three projects which are going to depend on glib.

I think that for the projects where it makes sense, glib dependency should 
be accepted. It is a pity to waste developer's time developing something 
that exists elsewhere in better and maintained quality.

What are the projects for which it makes sense ? Sofar, we've seen two 
- a KDE project wants to talk to a gnome project. This is the case for 
arts/gstreamer and kde-accessibility/at-spi.
- a project is developed within the scope of KDE but can not depend on Qt 
because the scope of the project is wider than KDE. That's the case for 

In both cases, the glib dependency makes sense.

For those who find it unfair that we accept to depend on a gnome project and 
not the opposite, look at glib. It is used heavily in gnome but it is not 
gnome. It is a library of utilities. The problem on our side is that Qt mix 
in one library many things: xml, containers, strings, widgets, shared 
library loader, database access, ...

The closest thing we have to glib is tinyQ 

Of course, I think it is important that we still ensure that KDE can still 
be built without glib. GLib should be an optional dependency, that will 
disable some features.



- Dad, why should we hide from the Police ?
- Because they use Emacs son, and we use Vi!

More information about the kde-core-devel mailing list