glib dependancy in KDE3.x

[Stefan Westerfeld]

   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)?

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-