[pulseaudio-discuss] libcanberra should be an optional dependency for pavucontrol
ozan at pardus.org.tr
Mon Oct 6 05:58:20 PDT 2008
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
> 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
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 ;)
More information about the pulseaudio-discuss