glib dependancy in KDE3.x

Alexander Neundorf neundorf at
Thu Mar 6 16:25:57 GMT 2003

On Thursday 06 March 2003 16:55, Alexander Kellett wrote:
> On Thu, Mar 06, 2003 at 10:25:53AM -0500, Maksim Orlovich wrote:
> > 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.
> but its basically inevitable that we must use something
> equivalent to arts functionality wise and there are none
> that are pure qtc++. 

Yes, but IMHO (and maybe a lot of others) it should be optional.
I have a simple SB (es1371) sound card with /dev/dsp1 and /dev/dsp2, for me 
this is really enough. I can run xmms on /dev/dsp2 and all other apps can put 
stuff into /dev/dsp. Even without this I didn't run arts, I don't need it, 
/dev/dsp works perfectly for me.
Actually I would like it if arts/another soundserver would be completely 
optional for KDE, instead of one of the things you have to build first.
And now even requiring a glib 2.x (I have 1.2 installed for xmms, gimp,..) 
only to be able to compile arts which I don't even install later on would 
make this thing suck more.

How about splitting arts in some way so that only the arts libs which are 
needed to build the rest of KDE are included in arts/ and the rest in 
kdemultimedia/ or kdebase/ or whatever ? Or a config switch for arts/ 
--build-only-really-required-stuff ? ;-)

Work: alexander.neundorf at -
Home: neundorf at                -
      alex at               -

More information about the kde-core-devel mailing list