Michael and Chris, thanks for taking a look at this. But I still don't understand why the system bell should be tied to the window manager. It seems to me a strange connection that leads to silly bugs like #430203. IMHO, the obvious solution is to let Pulse Audio handle the beep and leave the window managers out of it. Here's my reasoning:
- Just getting the basics of the proposed libcanberra solution requires writing new code in libcanberra and compiz. In contrast, the basics are already completely implemented in Pulse Audio; we just need to excise some code from metacity. - The libcanberra solution would require the same code in Metacity and Compiz (and gnome-shell and Unity, presumably). Each would have to be kept consistent with the library. This is not a worry with Pulse Audio. - I don't know how configuration with libcanberra would work, but it would require some sort of coordination for settings to survive changes in window managers. Pulse Audio keeps running though window manager changes. - Pulse Audio is a more obvious place for people with audio bugs to start looking. With Pulse Audio, there is still significant work to be done. Besides patching metacity, Pulse Audio's startup should be altered to make the loading of module-x11-bell optional and to load the appropriate bell sound. Additionally, gnome-volume-control would need it's system bell options rewritten to use Pulse Audio. Is there something I'm missing that makes having the window managers be responsible for the system bell so attractive? And regardless, should the discussion continue here or in a new bug for "Coherent handling of the system bell"? -- System beep broken in Karmic despite heroic efforts to fix it https://bugs.launchpad.net/bugs/486154 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to metacity in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
