Re: [GnomeMeeting-devel-list] Re: Sound events and GnomeMeeting

[Rodney Dawes <dobey free fr>]

On Mar , 2003-11-11 at 14:28, Glynn Foster wrote:
> Hey,
> 
> > A single alert sound is more useless than the current situation. At
> > least now, there is an API to set up a specific sound for a specific
> > event in an application. Sound event support is something that we need,
> > and when done well, can greatly improve usability and accessibility. It
> > also makes much more sense to have different sounds for different
> > alerts. Having a buzzer sound for new mail, instant message, or low
> > battery doesn't make much sense, while it may make sense for an error.
> > The URL below should help explain what i mean.
> > 
> > http://www.pixelcentric.net/x-shame/sound.html
> 
> Absolutely, and I wasn't suggesting that we remove the API for this, but
> rather remove all the application specific sound events from the capplet.

I still don't think this is the right thing to do. It's basically the
only thing in the capplet that is worth having the capplet for. It
provides a nice interface for theming sounds, as well.

> I believe we really only need one sound event for 'alert'

Again. This is just something that would never be used by much, if
anything. You can't have one sound to notify you of 50 different
types of alerts. That is just broken. And it has to be configurable.
Audible awareness is very much a part of the Look and Feel of one's
desktop. It is very similar to the Low Contrast/High Contrast/etc...
accessibility and theming issues that are present with Widgets and
their colors.

> across the desktop, and let other applications use sound events where
> appropriate. Hrm, sounds like a section in the HIG to me.

We do need something in the HIG to better inform people of what sounds
to use, and when and how to use them. We don't need to add yet another
configuration page to every single application that wants to use sound
events, because it will just make those applications that much more
complex. I think having a cross-desktop configuration solution that
allows theming, is the best way to take care of the problem of having
multiple sound events and configuring them. Basically, this was my goal
with the sound theme spec I tried to propose a while ago on xdg-list. As
I said in my last reply to you, I would be glad to re-start that
initiative and get it somewhere useful.

> > Yes. Just not on GNOME. :) Or at least, enabling them and not installing
> > gnome-audio, will at least get rid of all the annoying sounds for the
> > gtk+ button press events. They are useful, despite how any current API
> > in GNOME may lead you to believe otherwise. :)
> 
> If they are useful, then why didn't someone complain that they weren't
> there? certainly sounds like they're not being used all that much ;)

Because they are buggy, and it has always been easier to ignore than to
complain about it and get it fixed. It's a difficult problem to solve,
and speaking from a user's perspective, very hard to communicate what
one thinks is wrong, to members of the developer community. If I had the
time, I could install every gtk+/gnome application that exists and make
a list of all the applications that use sound events, but I don't have
that time. User's are adverse to using the sound events, because there
are annoying bugs that are non-trivial to fix. For example, open a large
document in AbiWord, and change the scaling of the document. If that
doesn't cause the toggle buttons in the toolbar to activate enough times
to make you want to turn them off, then start at the top of the
document, and hold down or page down for a while and listen to the sweet
harmony of the button clicking sounds. Yes. This is why people turn the
sound events off.

> > Lots of things use the sound events API. Gnomemeeting for example.
> > However, it's currently a pain to do sound events the GNOME way,
> > because the API has its issues, the event support is disabled by
> > default, and 
> 
> Hrm, and that's why I was advocating that we should have a simple API
> for this, and perhaps put a little bit more faith in the gstreamer API
> and use that directly.

Throwing a new multimedia framework at an old problem won't solve it. In
fact, just shoving gstreamer under the sound events API right now, will
probably actually cause more problems. You still need a sound daemon.
The latency or whatever other current issues exist, probably won't
improve. And, you'll be introducing threading issues *and* co-threading
issues into the arena. I'm not against using gstreamer, btw, if that is
what this sounds like. I am only against trying to solve problems by
throwing technology at them. As a short term solution, having
GnomeMeeting do it's own thing and just shove the sounds through pwlib,
as it is doing with the voice already anyway, seems like the best
solution. In the long term, a new sound daemon that is cross-platform
and that handles the issues of latency and networked environments, is
probably the best solution. I don't know how far MAS is, or what issues
it has, but it seemed very much to me that those guys had the right idea
about what to do in order to solve our problems with sound daemons.

> > > [1] For screenshots of what OSX and XP does, take a look at 
> > >     http://www.gnome.org/~gman/sound-capplet/
> > 
> > Was this supposed to be an example of what not to do, or what other
> > desktops currently do?
> 
> What other desktops currently do. As you can see, there is a *HUGE*
> difference between the OSX way, and the XP way.

http://primates.ximian.com/~dobey/screenshots/multimedia-properties-sound.png

This is a mockup of the sounds page of a new multimedia capplet for
GNOME that I made back when I made the initial draft of my sound theme
specification. It was basically a straight rip of the Windows sound
capplet in ME. An initial draft if you will. I will rethink parts of it
and make a better mockup soon, but it seems like something we definately
need. Maybe it would be a good idea to put up more screen shots of what
other desktops like KDE, BeOS, QNX, and XFCE do.

-- Rodney