On Fri, 12.12.08 02:00, Iain (i...@gnome.org) wrote: > Some thoughts on sounds.
Here's my response as one of the guys who wrote the specs and as the one who implemented them. I'll probably repeat a lot of stuff other people said. Sorry for that. 1. This should be discussed on the xdg mailing list. 2. I think you underestimate how many people use event sounds. Since I started to hack in this area I am actively noticing that surprisingly many people enable them, including the input feedback stuff. And not just crazy people but also hackers at conferences (i.e. tech people!). Please note that I don't use event sounds that much myself, and a year or so or two I didn't think *anyone* would. But I was wrong, people use them, although the ones we used to ship are quite annoying. While most sounds are used only by a minority, sounds for email, IM and suchlike are used by huge majority of people, especially when they use non-Linux OSes. On Operating Systems like MacOS where the shipped sounds are high quality a lot more people leave them enabled. In Windows this is similar, although the sounds are worse quality. Heck, some sounds (like the Windows startup sound) even entered pop culture in a way. Finally, don't forget things like the venerable MS Plus! which included theme sets which included sound themes. Also, don't forget accessibility. Just because you don't use them you should not assume nobody does. Because that is simnply wrong. 3. I know of at least 3 sound themes right now. Our upstream version, a Mandriva theme and some Ubuntu "Human" stuff. 4. You can easily coalesce multiple event sound files using the dash notation, as pointed out by Marc-Andre. Even if we list 125 sounds, that doesn't mean you'd have to define them all seperately. Also note that the new sound theme dialog coalesces quite a few of those events into one. And it is intended that way: the set of event sounds generated should be extensive and the meta information about each event should be verbose. However, only a subset of these sounds should be exposed in the config UI or defined in the themes. How fine grained this is chosen is left to the UI or theme designer. 5. libcanberra support slipped in in the last GNOME version as blessed dependency very very late. Only a minority of programs use it right now. Don't expect an adoption from zero to 100 in no time. 6. The 125 sound names don't come from nowhere. We looked around on the Internet for sounds that are already in use. i.e. the sounds Windows defines, GNOME defines, MacOS defines, KDE defines. The sounds different applications define, and sounds people have publicly requested. For almost all sounds listed in the spec there is at least one pre-existing example where it is used or available. Please note however, that we only included sound names that made sense to us. So if you do the full survey again, you might end up with substantially more than 125 sounds. And again, just because we list 125 sound, it doesn't mean you have to actually define them all. You can easily coalesce them due to the aforementioned dash notation. Also note that some people mentioned that they thought the icon naming spec was handled too conservatively. We explicitly want to be a bit more liberal about what we include in the sound spec and what not. (Of course we won't include *any* random bullshit people ask for...) 7. You claim the list is too large but incomplete at the same time. Sure it is incomplete . We are happy to add more entries when they make sense. The barrier is low for new additions. 8. In contrast to what you claim it is dead easy to create a sound theme. Simply base your work on the fdo theme and replace the wave files. A monkey on a donkey could do that. Of course you can do it more elaborately than that if you wish, but you don't have to. > With sounds like window-new, window-move-start, window-move-end, > window-minimized, window-unminimized will the computer ever be > silent? You can disable any sounds or subset of sounds you wish. The KDE sounds for these specific events are very subtle btw. w-m-s for example is both very low in volume and frequency and actually pretty good. > There is a principle applied to dialog boxes, called the butler principle[10]. > When there is a knock at the door, the butler doesn't ask if he should > answer the door, he goes and does it. > He also doesn't tell you that he's going to do it, he just does it. > I think this should be applied to sounds as well as dialogs. > If the butler requires the master's attention, he does it subtley, > making a discrete *Ahem* > not by screaming "HEY I NEED TO TALK TO YOU!" And so? Of course it's fine to define themes that are subtle. However, if your hardware is breaking or suspending failed while you closed your laptop an annoying sound is more adequate. > The sound theme spec[3] defines four[see footnote 4] categories; > Alert, Notification, Support and Game. > I think these 125 sounds spread over the 4 categories can be reduced > to a single sound [5]. That my friend is ridiculous. Are you aware that I find it quite informative if can discern the sound that is played when a CD is finished burning from the sound I get when I get a new mail? > Firstly the Game category can go. Its not really sounds for games > anyway, its sounds for card games. How did you come to that conclusion? Because non-card games know no winners nor losers? > Secondly, throughout the other 3 categories, the sounds are either > a) Very application specific (i.a. the camera sounds, the phone sounds) > b) State the obvious (i.a. lid-close and lid-open. I know I've closed > the lid, I don't need to be told about it[7]) Stuff like power-plug and unplug is certainly not obvious. It's a warning sound. You are excessively oversimplifying this. Also, maybe the next time you take part in the discussions when we first asked for comments about this, instead of raising it after we already pushed through with everything. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
