glib dependancy in KDE3.x

[Maksim Orlovich]

On Thu, 6 Mar 2003, 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.*).

And what would happen if a bug in glib broke aRts? 
aRts is already a major maintenance hassle -- few people understand how it
works, and the GSL code is just awful.  Tracing out the memory
corruption in it (the gsl_foo_magic) for me was no fun -- particularly
since following your instructions about it not being developed here, I've
sent a patch fixing  the problem to you, only to have it ignored for
months, and later fixed  indepedently by an another developer. The same of
course can happen with any external dependency. Pretty much every outside
lib we depend on has been a problem one time or another - libxml breaking
docs build, glibc linker bugs killing designer, and of course Qt bugs
breaking things do. The latter of course were always th eleast problem
since practically any KDE developer can look at Qt code and fix most
things.  

IMHO, unless we have absolute guarantees that any bugs would be handled by
the maintainer promptly, which is rarely the case with any KDE apps,
including aRts (seeing that bugs in aRts libs crashing Konqueror has been 
reported from early 2.x days all the way to 3.0.x), putting in that kind
of code in there is a mistake.