Re: Desktop sounds in Gnome

Thomas Wood wrote:
On 23 Mar 2007, at 19:26, Glenn J. Mason wrote:

things super simple from a user perspective. Do we really need, and
users really care about, different sounds for questions,
battery low, etc.

my personal opinion is no, we don't need all that. So, the question is,
are there users that use and like this functionality?
Personally: yes, I like the functionality very much! I have cordless headphones and often walk away from the compy whilst it is doing something which might take a while (CD burning, downloading, updating). I really like being notified audibly, and the different "urgency" I can assign to it -- a question? I'll wander back. Battery low? Find transformer and run!

Laptops often make their own noise when running low on power anyway. Anyway, I guess there's a possible argument for two sounds to represent critical and non critical alerts. The point here is would anyone want to change all these different noises if they were really good quality to start with? iTunes makes a noise when it finishes ripping a cd (which is only mildly useful to me at best), and I don't see an option to change it if I wanted. Not that I ever would probably...

And that's before even considering accessibility, etc.

I was wondering when someone would bring this up. It doesn't make much sense to me, as you're probably going to be using a screen reader anyway, so you don't need to learn half a dozen different sounds because you already know the spoken word. However, I'm not experienced in this field so it'd be interesting to hear from someone who is.
Regarding sound alerts and themed alerts, first do no harm. That is, the themed alert sound shouldn't clobber the screenreader. (e.g. on Ubuntu Edgy, the screen reader doesn't work unless sound events are disabled.) While it's true that OSX has only one system wide alert sound, it has been possible to configure speakable alerts since MacOS 9.0 or earlier. This made per event alert sounds less necessary. Speakable alerts don't have the functionality of a screen reader, but they are useful when your display isn't working or when you aren't looking at the display. Would it be useful to review previous GNOME sound architecture? What deficiencies in esd, gstreamer... prevent us from wanting to move forward with these? We've learned a few things by finding and fixing bugs with previous GNOME sound daemons. For example, I hope any new sound architecture takes the following into consideration:

1) Work with screenreaders, VOIP and streaming audio/video players, not against them. 2) Don't assume that the user is at the console. (e.g. on a thin client or remote X display, the sound should come out of the client, not the server.) 3) Don't assume that you have sole access to an audio device and don't assume that there is only one audio device on a machine. 4) Don't lock the sound API to a specific architecture (e.g. X86), specific kernel (e.g. Linux) or specific sound hardware (e.g. soundblaster...) 5) Try to avoid sucking resources when idle and be reasonably efficient when in use.

Can the ekiga and gaim developers let us know what would help them? I find that relating sound events to IRC events (e.g. my name mentioned on a channel) is extremely useful. Unfortunately this isn't yet reliable. And wouldn't it be cool to have this somehow fit in with sound themes. Each sound themable application (ekiga, gaim, evolution, nautiulus/panel/metacity) would expose a list of events which could be associated with sounds. Sounds could be dropped from a sound pallet or pulled in together from a sound theme. Hmm, it's starting to remind me of my mobile phone:

                                             Home        Sun
   my name is mentioned        pfft            ping
some leaves the room Evolution:
  Email received                     blurp         pfft

System Alerts:                       speak %s     speak %s

I know this can be done per application, but wouldn't it be fun to unify, remove some redundant code and allow for a common user interface?

desktop-devel-list mailing list
desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]