unity-design team mailing list archive

[Dylan McCall <dylanmccall@xxxxxxxxx>]

On Wed, Jun 16, 2010 at 3:18 PM, Frederik Nnaji
<frederik.nnaji@xxxxxxxxx> wrote:
> On Wed, Jun 16, 2010 at 16:48, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>
> wrote:
>>
>> It's just a menu, it's not reinventing the audio system.

Ah, of course. Thanks :)

I was mainly worried that there _was_ reinvention going on, so I'm
happy to know that nothing goofy like that is in the plan.
I think I will chat with one of the PA guys, or find out more about
its master volume stuff. (Maybe it does something amazingly clever
that I don't know about). For now, though, I'm back to just looking
forward to that awesome spec being implemented.

>
> ..yet it's close to reinventing the audio backend's interface to the
> technically unaware user.
>>
>> "The menu should give easiest access to the volume of the primary sound
>> output device and the primary sound input device. Other devices can be
>> accessed through the Sound Preferences window."
>> <https://wiki.ubuntu.com/SoundMenu#Menu%20structure>
>
> yeah, great ;) That helps keep things orderly.
> Devices aside (OT anyway), how about treating applications like GlobalMenu
> does?

The panel is meant to be detached from the rest of the desktop. That
means it looks the same on all workspaces no matter what window is
currently focused. Unfortunately the window list is an exception to
this (grr…), but you'll find the behaviour holds very consistently
outside of that.

> When e.g. Totem is focused, why not focus primarily Totem's options in the
> sound menu?
> imagine the following scenario:
> 1. start a song in Rhythmbox
> 2. hide main Rhythmbox window with the proposed "hide" button
> 3. raise e.g. Abiword to compose text
> 4. access Sound Menu to change Rhythmboxes volume
> The use case in which i would need a "main volume" slider is rather a
> workaround for not knowing which app is disturbing.
> For this we have the single sliders in "Applications" within Sound
> Preferences.
> Also, "Sound Preferences" is not a good name.
> my thoughts, condensed:
> * make Sound Menu behave like GlobalMenu
> * give Sound Menu > Sound Preferences > Applications a more accessible
> semantic path

I think that last bit is a good point. We have a lot of similar cases
floating around, where all sorts of functionality is crammed into a
generic “Preferences” window. It gets weird when these preferences are
really designed to be accessed routinely. There should be a rule:
don't call anything a Preference if its value is changed through
normal use of an application.

In hunting for a specific example just now, I noticed gcalctool
currently has “Angle units” under its Preferences!
To change the map in Mahjongg, you go to Preferences, whereas “Enable
toolbar” is an option accessed in a single click from its “Settings”
menu.



Back to the Sound Preferences, two things suddenly became apparent to
me, which I hadn't really noticed before. I'm looking at this from
having used indicator-sound, then selected “Sound Preferences…;”
changing the volume is the first thing on my mind.

The first thing I see is “Choose an alert sound,” then that I'm in the
Sound Effects section where I pick a sound theme to use. Ideally, I
will use this section once ever when I first set up Ubuntu, to switch
to the Freedesktop sound theme. I am an exception; I'll bet most
people wouldn't even touch this, since there are so few sound themes
out there right now, there's only one by default, and it's difficult
to install them. This is a good candidate for a preferences dialog.
(And I understand there's a GSoC project to make this part a lot
cooler. Yay!)

In order, the next section is configuring hardware devices. Again,
shouldn't need to use that section more than once (PA tries to sort
these out automatically, right?), and it doesn't change anywhere else.
Great!

Now we get to Input device, Output device, and volume for individual
Applications. Those are options that people probably _would_
manipulate more than once ever. They are all related to what is going
on Right Now, they are all quick to change, and I don't have the same
expectation for the state of these things to be preserved. Applying
this to my test, the values controlled can (and do) change outside of
Sound Preferences (like Rhythmbox's own volume control), but the
controls themselves also change! Rhythmbox is only controlled under
Sound Preferences›Applications when it is running.

To me, this is begging to be split into two windows. One being
preferences, the other being Volume Control. As a simpler approach,
gnome-volume-control can be told to show the more relevant section in
this context. Running gnome-volume-control --page=applications from
indicator-sound does the trick ;)


Thanks,
Dylan