On Fri, 30.10.09 10:54, Jeremy Nickurak (jeremy at nickurak.ca) wrote: > On Thu, Oct 29, 2009 at 19:11, Lennart Poettering <lennart at poettering.net> > wrote: > > This is admittedly a problem, but I kinda hope that it will fix > > itself by applications tagging event sounds properly. Even for legacy > > applications you can do that with minimal work most of the time: > > If the options are: > > 1. Fix it once in pulseaudio, and win all applications working right, > even legacy unmaintained ones that nobody's ever going to fix, or > 2. Wait for all the application developers to get on board with a new > protocol, even if they aren't maintained any more As mentioned this is not true. Setting up those property env vars is very easy even for legacy apps. Also, the number of apps that actively generate event sounds is minimal anyway, and I think we have already covered already about everything in that area. > .. I'll give you 1 guess which I think is more realistic :) I disagree. But you know, if we disagree on priorities there's nothing hindering you to produce the necessary patches and fix things yourself. > 2) is tantamount to saying "Well, everybody should just do this the > pulseaudio way, because that's the right way." It may very well be, but > you're not going to sell pulseaudio as the "right way" to the enough > developers to have a consistent user experince without several *years* of > stable adoption, especially with the current state of bitterness about > pulseaudio rollout in current distributions. (If we can't count on the > distros to do it right, we have about as much hope as a snowball in hell of > getting all the little one-off developers on board) Dunno. You are exaggerating here. Event sounds are a tiny playing field, and we covered almost all of it these days -- unless you run archaic distros... Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
