On Mon, 2004-05-24 at 18:14 +0000, Thomas Conneely wrote: > As I understood the situation, the aim is to move away from the files > and applications towards documents and uses. Using audio types allows > the user to immediately undestand what sounds are affected by the > changes (as long as applications properly register). With application > having own channel on mixer they would have to know which application > did what. If the applications register a name that is HIG conscious then the name that shows up will be task based. > Also they wouldn't have the option to have different volumes for the > same application e.g. when using totem for mp3 and movie playback (for > whatever reason) I might want my MP3s to be loud, whilst when I wish to > play a DVD I want the volume to be quieter. This would also allow each > audio type to have its own eq settings and other properties e.g. > surround sound for movies stereo for mp3s. This could be accomplished without classifying audio types. If apps could register multiple volume controls (something I considered adding to my earlier post re: mixing apps) then an app with multiple volume settings (I don't know any off the top of my head that currently fit this) could register multiple controls. This would fit your use case for Totem, but I don't think I agree that its a good idea. Even within Totem, whatever the UI, I think having multiple volumes (one for DVDs, one for Music, one for TV) is overkill. Watching movies with sound while listening to seperate music is an unlikely case. The hypothetical "Sound Engineering" app seemed like a better candidate for multiple volumes. In this case, where multiple volumes are integral to the use of the program it seems that having a custom UI in the app would be expected and more useful than just putting sliders into a central volume control. -Brian
Attachment:
signature.asc
Description: This is a digitally signed message part