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

[Rodney Dawes <dobey free fr>]

On Hën , 2003-11-17 at 19:12, Glynn Foster wrote:
> Hi,
> 
> > > 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.
> 
> What makes you think that we need themed sounds in the desktop? The
> article doesn't exactly suggest it, and in fact seems to suggest that
> the M$ type jungle/space/train/... sounds are overkill.

What article? The pixelcentric URL I posted mentions nothing about the
jungle/space/train sounds. The way Windows does sound events is
overkill. But that's not to say that it's not partially correct in the
way it does do things. I have stated already why I think we need themed
sounds in the desktop. If I have my desktop set up with a jungle theme,
why would I want to hear non-discriminate corporate desktop sounds?

> > 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.
> 
> So have 50 different alert sounds for 50 different applications? I'd
> very much like to hear Bill/Calum's thoughts on the issue.

That is not what I said at all. 50 alerts was just an arbitrary number.
First of all, you wouldn't have 50 alerts playing at the same time. And
the sounds need to be configurable so that they go along with the look
and feel of the desktop. Looking over the responses from Bill and Calum,
it seems that they mostly agree with what I've been stating.

> > 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. 
> 
> Yes, but most applications shouldn't need sounds. Sure, for things like
> instant messaging, video conferencing, games they might be desirable,
> but for most other things there is no requirement.

The things that don't need sounds for events are irrelevant. They aren't
going to use whatever interface we provide, anyway. However, having the
configuration for those things be in a central location, is something
that will keep consistent with current UI, and will keep applications
from becoming more complicated and dispersed.

> > 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.
> 
> Well, whether it's cross-desktop or not, we still haven't identified
> what the user requirements are, and what tasks if any are they likely to
> do that involves sound theming. I'd certainly like to get those more
> concrete first.

The user requirements are pretty simple. Play a specific sound when a
certain event happens. Theming basically involves configuring a set of
sounds and storing it in a theme. You need to be able to name the theme.
Beyond theming, there really aren't any "user tasks". It's all backend
implementation issues. Maybe enabling/disabling individual events.

> > > 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. 
> 
> Hrm, I think you're confusing 'buggy' with 'arse'. One of our CEO's has
> specifically asked for a new login sound because the current one really
> sucks.

This is a perfect example of why we need themes. Corporate executives
are probably going to want some very different sound scheme than what a
16 year old punk (musical genre) kid might use.

> > 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. 
> 
> Currently I see the following in my sound capplet -
> 	
> 	o Gnect, Gnibbles, Gataxx, Iagno, Robots
> 	o gnome-meeting
> 	o battstat
> 	o mailcheck
> 	o gnome-session
> 	o user interface clicks, toggles, ...
> 
> and Gaim, which seems not to use the gnome-sound stuff. This doesn't
> seem like a huge proportion of GNOME applications.

These aren't all available gtk+/gnome apps. GnomeICU uses the sound
events api. Gaim has historically been ill-tempered about integrating
with gnome and linking to the gnome libraries. I don't see why a huge
proportion of existing applications would have any more effect on doing
something one way, as opposed to another. If I made a large list of
non-existent applications that could use the sound events API, would
that help sway things any?

> > 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.
> 
> Which kind of suggests that they didn't need the sound in the first
> place. If they missed it they would complain.

Subtle sounds for some widget events do help to enhance the user
experience. Overdoing it of course, does not. 

> > 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. 
> 
> No, I was suggesting that we don't need the current sound events API,
> and that people should just use gstreamer directly - it seems to work
> well for monkeybubble and others..

I don't see how requiring every application to use gstreamer directly,
would simplify things. If anything, it will complicate matters and put
an even bigger burden on developers that do need sound events. Odd. I
couldn't get monkeybubble to play any sound at all. I've had nothing
but problems with totem. It likes to take up all my cpu, and lock up
when trying to exit or remove something from the playlist.

> > 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.
> 
> Certainly seems a little too confusing currently. I don't really see the
> need for 'Play' or 'Save As'. Perhaps s/Browse/Install seems more
> consistant with other capplets. Think we could probably remove the Name
> and Theme combo boxes too, with a clever enough design.

Play is so you can preview what the file sounds like. Save As is to save
the custom settings to a theme. And, you wouldn't be installing a sound
theme when clicking on Browse. You would be browsing to the file to use
for the selected event. The "Name" box can be integrated into the tree.
The "Theme" box needs to be there somewhere, so you can select the theme
to use. Themes are the entire point of the dialog. Adding an Install
button may make it more consistent with the theme capplet, but I don't
think the Install buttons there make much sense anyway. It doesn't work
for all themes.

-- dobey