GNOME Volume Control mockups:
So, many comments and help on my mockups. Apparently, they help. ;-). Glad
people like them.
So, some terminology. The user doesn’t need to know them, but just so people
know. A single soundcard representation is called an element (e.g. SB!Live
[ALSA]). A single sound particle in an element (e.g. line-in) is called a
track. A single slider is called a channel (left, right). Mute turns off
sound on your speakers and/or headphone when selected. Record turns on
sound capture from input tracks such as line-in. Tracks with record turned
on will be captured when read()ing from the device. Other tracks will be
ignored. Lock groups individual channels in a track together, so if I change
the volume on one channel, all other channels in the same track will move to
the same value as well. All UI-visible aspects of this are explained in the
manual (Help -> Contents), kindly provided by Sun Microsystems.
Oh, ALSA (in its API) calls tracks elements. Elements are called handles. Nevermind the
consequence.
Tybstar, on IRC, was the first to give some helpful comments, mostly related
to spacing in the window between sliders, between tracks, etc. Mostly some
finetuning of the window mockups to the UI guidelines and the HIG. Thanks
for that, will work on that. Got some UI tips from Havoc as well, in his p.g.o
post, will look at those as well, most sound good. This is stuff like layout, naming and tooltips-on-sliders.
Benjamin (on IRC) and Havoc (on p.g.o) gave some more terminological comments.
Nice to know that people care about that. That’s somewhat hard, though, not
in the last place because the kernel has no single interface that is suited
for that job. In other words, it’s gonna be incredibly hard, if not completely
impossible, to acquire all the necessary information that is needed to get
g-v-c up to the level that they propose. I’m also not sure if it’s what end
users expect. Other comments are very helpful, though, so let’s see about
some of those in detail.
Volume Applet, GNOME Volume Control and Applications: the volume
applet is supposed to be the fast’n’simple accessor for volume control. Any
simple control to your master volume should be done via that applet, and any
user should have that exposed on its menubar. GStreamer’s mixer API (more
on wording later) has a MASTER_TRACK flag somewhere to see which of the
tracks is the master track. GNOME Volume Control is not for any simple stuff.
Benjamin proposed a “simple” version where I can change “output volume”,
“input volume” and where I can manually show tracks if wished for. This is,
according to one of my housemates, similar to what Windows XP does.
This is not a good idea, imho. It’s practically impossible and/or unwanted
for 2 reasons. The first is that we downgrade any user to the lowest common
denominator of all types of users, and give him no more control (by default)
then this. Benjamin replied that advanced users would use alsamixer anyway.
Well, alsamixer is not part of Red Hat, Fedora or SuSE’s default installs and
shouldn’t be an end user app because it’s commandline only. GNOME should have
a similar “alternative” for its power users. The second reason is that, at
least for inputs, we’d be changing all volumes to one value. The effect of
this is best explained by telling what it does on inputs. Setting PCM and
Volume tracks both to 90% will result in much more noise at the same audible
loudness then when Volume is set to 80% and PCM to 100%. This is hardware
imperfection and cannot be fixed or detected in software. For simple stuff,
look at the Applet. For complicated stuff, use the Volume Control. Changing
the CD playback volume or just changing volume (Joe User vs. Joe Hacker) are
both simple and valid use cases…
Applications will always show just the one or two controls that they are
interested in. I don’t think that means we should leave them out from the
main volume control applications. Windows doesn’t do that either, neither
does Mac OS X.
What I *am* planning on is to hide a lot of those tracks by default.
Particularly all of the options and quite some of the more complicated
input/output tracks. There’ll be a preferences window (returning from pre-2.4
days) to hide/show tracks as the user wishes, but the default should make
sense for a default user.
I’m definately not gonna add an advanced and simple mode, like Nautilus-1.x
or Windows XP. It’s not right ™.
Volume Control vs. Mixer: naming confusion. I called it mixer in the
beginning, and felt bad about that later on. I decided to call everything
in the UI Volume Control from now on. Mixer is too technical.
Signals: or, well, rather, GNOME Volume Control updating sliders’
values if I change volume in the Volume Applet. Will be worked on shortly,
right after the UI is fixed.
Menubar: well, since we’ll re-introduce the preferences screen, and
the Help -> Contents explains some terms used in the UI (should I use icons
like the ones from the GIMP instead?), I guess we can’t really remove this
just yet.
Headphone vs. Speaker Volume: not possible, I’m affraid. Nice idea,
but there’s no way to get the required information from the kernel.
So, in the end, some hints are useful, some are debatable and some are – at
least now – impossible. I’ll try to find the golden middle road. Please give
me more feedback, it’s very useful and makes me realize a lot of details and
all that about UI development – good thing!
Edit!
Apparently, all sort of people sent me emails as well, I forgot to read my email for the past few days because I went to PS1 (yay for parties in Queens!) yesterday. I’ll read those too, I promise!