Colin Guthrie wrote On 06-10-2008 15:09: > Ozan ?a?layan wrote: > >> The GIT branch of pavucontrol and the latest stable release strictly >> depends on libcanberra for managing the event sounds' volume. I think >> that this dependency should be made "optional" so that the distributions >> with KDE desktop environment can compile it without depending on >> libcanberra. >> > > I agree (ish). While libcanberra is the defacto implementation of the > sound theme spec, it is just an implementation and if an alternative > library is written (e.g. for use in Qt - and yes I know it would make > more sense to use libcanberra for Qt, but this is just "in theory" ;)) > that also implements the spec, then pavucontrol would not compile there. > > That said, libcanberra itself is very easy to compile and if pavucontrol > is just using it as an implementation of the spec in order to generate > an appropriate UI, then IMO I think that's fine and you should just > compile libcanberra and ship it. > > > I guess the bigger question of "do you want the sound theme part of the > pavucontrol UI compiled when the desktop does not support it" is really > what needs answered. > There's no problem in shipping libcanberra "but" KDE 3.5.x/Qt forwards event sound playback requests to arts daemon(artsd) and artsd plays them using PA. I'm appreciating the work done in libcanberra, it's very simple and exciting but I don't think that the necessary integration will be done in KDE 3.5.x/Qt as it's mainly a bugfix branch. KDE 4.x uses Phonon. As KDE 3.5.x/Qt doesn't integrate with libcanberra, the sound system volume control widget in pavucontrol becomes useless. So, your bigger question is the right question ;) Anyway, I'm reverting the corresponding two (a32b21a4174cf37.., ecc9ad9b06184dc2a4...) commits assuming that the commits are atomic and doesn't modify anything else because I don't have any gtk knowledge ;) Cheers, -- Ozan ?a?layan
