glib dependancy in KDE3.x

[Allan Sandfeld Jensen]

On Thursday 06 March 2003 10:03, Stefan Westerfeld wrote:
>    Hi!
>
> I have found that not depending aRts on glib causes a lot of additional
> maintainance overhead. Arts maintains its own threading abstraction, its
> own mainloop, its own locks, its own glib mainloop integration, and a lot
> of additional code duplication (~/src/arts/flow/gsl/gslglib.*).
>
> Not only is this wasted time, at this point I don't see any reason to avoid
> that KDE4 depends on glib, because its fairly certain that the best
> abstraction for media streams out there is GStreamer. Not accepting glib as
> "valid platform for implementing things" also is the cause of lots of
> interoperability issues with GNOME.
>
> Its like one important reason which currently splices the free software
> development community into two pieces ; unnecessarily so. Because if you
> implement anything in C, then you will want to depend on glib, because
> otherwise, you have no sane programming environment at all. You need this
> for mainloops, for threading, for data structures like lists and
> hashtables, and so on.
>
> Thus, I am considering removing the glib compatibility code from aRts, and
> depending on the real thing in the future. The question is: are there any
> objections and/or comments against doing this within the KDE3.x cycle (i.e.
> for KDE3.2)?
>
It seems there are only two sane options: Depend on Qt and C++ or glib and C. 
I you think using glib will make arts more widely used, then sure go ahead.

Personally I would prefer Qt since that would make the technology behind KDE 
more consistent, but that would take some rewriting of arts I guess.

`Allan