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
>>>>
>>> do
>>>
>>>> users really care about, different sounds for questions,
>>>>
>>> information,
>>>
>>>> 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
GAIM:
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?
> -Thomas
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
