Re: GNOME CVS: libgnome martin
- From: George <jirka 5z com>
- To: Bill Haneman <bill haneman sun com>
- Cc: Michael Meeks <michael ximian com>, Alan Cox <alan redhat com>, Tim Janik <timj gtk org>, Hacking Gnomes <gnome-hackers gnome org>, gnome-2-0-list gnome org, gnome-accessibility-list gnome org
- Subject: Re: GNOME CVS: libgnome martin
- Date: Mon, 13 Aug 2001 13:43:50 -0700
On Mon, Aug 13, 2001 at 11:48:49AM +0100, Bill Haneman wrote:
> Joe Shaw wrote:
> >
> > On 11 Aug 2001 16:29:54 -0400, Michael Meeks wrote:
> >
> > > It also strikes me that the accessibility guys will need to be
> > > able to play sounds on events; and that it seems entirely likely to me
> > > that they will be able to do it 'right' at some stage, probably soon.
>
> Actually the ability to play sounds on events is not the big headache
> with
> sound+accessibility; for users who need it (vision impaired, possibly
> cognitive disabilities) we can use the at-spi to monitor various kinds
> of
> events and the assistive technology can use the sound engine of its
> choice.
> Eventually we will definitely need a "nice" streaming/multiplexing
> sound
> API for speech and audio notifications, but that can wait a little
> while.
>
> The big issue, and it is pretty important, is with Gnome applications
> that
> give audio notifications. In the case of those applications, we need
> to be
> able to intercept these notifications and provide alternate
> notifications
> (flashing screen, etc.) for the hearing-impaired user. What we can't
> have,
> from an accessibility point of view, is lots of apps doing this in
> their own
> inconsistent way: we need a common API for all such sound
> notifications, so
> that we can intercept and substitute at a single point. This needs to
> be
> a control panel/theme function - and obviously it has value not just
> for the
> hearing-impaired but for the audio-driver-impaired (e.g. some laptops,
> etc.)
> It sounds to me (pardon the pun) as though the current 'solution' for
> Gnome audio is a free-for-all that would make such a consistent
> audio-notification
> policy unworkable. Certainly the minimalist API proposal that is
> floating
> around would be a better solution for accessibility. Even better
> would be
> a gnome_audio_notify ("bin-bong-file.au", "Alt. Descriptive String").
Well the API that is currently used that was apparently just removed is this:
static const char *supinfo[] = {"panel", "collapse", NULL};
gnome_triggers_vdo("", NULL, supinfo);
That will tell the triggers api to do whatever it does when the panel
collapses. It could be a sound, it could be whatever. Currently afaik, only
sounds are implemented.
Perhaps this API sucks. Oh well. Perhaps the implementation sucks. Oh
well. But removing it before we have an alternative sounds stupid to me.
The user doesn't really care about either of these points. For the user
the only visible change will be that gnome suddenly sucks more.
I really don't want to do
esd_play_sound_whatever_this_function_is_called
(PANEL_SOUNDS "/swoosh.wav");
Because it just sounds like the very very wrong approach to me.
George
--
George <jirka 5z com>
Where all men think alike, no one thinks very much.
-- Walter Lippmann
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]