XDG Icon Spec: requesting new icons for headsets, speakers, headphones
mzkqt at 0pointer.de
Wed Mar 18 13:56:18 PDT 2009
On Wed, 11.03.09 09:40, Rodney Dawes (dobey.pwns at gmail.com) wrote:
> On Wed, 2009-03-04 at 12:18 +0100, Lennart Poettering wrote:
> > Heya!
> > This hence boils down to that I'd like to ask for the following five standard icon names:
> > - Speakers (i.e. external USB speakers or suchlike)
> This is really what audio-card was supposed to be. Having an icon for a
> specific audio card is really pretty pointless. I'm not sure what to
> rename it to though, at the moment.
Not sure if I agree. I think it makes a lot of sense to distuingish
the genric idea of "audio" from actual playback with speakers,
headsets, headphones, and so on.
> > - TV
> This is covered by video-display really. How is a TV different from a
> monitor with speakers? Perhaps this should be renamed to just be
> 'display' though, as video- is a bit redundant.
OK, I will now use video-display for this case.
> > - Headset
> > - Hands-free
> As Bastien noted, I'm not sure how these are different. And having icons
> for Bluetooth profiles doesn't make sense, I think, which is what the
> latter is. A BT headset and a BT 'hands free' kit in a car both use the
> same hands-free profile. What matters is the model information we get
> from the device when we query it, not what profile it is connecting
Uh, BT actually distuingishes the HFP (hands-free) and the HSP
But this is not really about profiles. This is about device "form
factors". We usually know pretty well if a device is actually and
physically a headset you attach to your head or a hands-free kit that
is built into your car's dashboard in some way. This information is
completely unrelated to the protocol we actually use to access the
That said, the priority for me is to have an icon for the headset,
hand-free is only second priority.
> > - Headphones
> I also think 'headset' for example, is a superset of 'headphones'. All
> headsets provide at least one speaker, but all headphones don't provide
> a microphone.
Sure you could say that headphones are a superset of a headset in some
ways. In other ways however that's not true. But does this matter for
the icon situation?
There are a lot of ways how a headset is different from headphones:
a headset usually has mike+mono speaker, headphones only stereo
speakers. headsets are optimized for speech/telephony, headphones for
music/hi-fi. headsets thus usually provide only very low quality
speech-optimized audio, while headphones do high-quality hi-fi-esque
audio. Headsets usually provide some buttons for call
control. Headphones usually don't.
> > Opinions?
> I'm not sure how to name some of these exactly. And I'm not sure I see
> much point in differentiating some of the pieces. For example, the input
> and output portions of a headset, you will almost always want to control
> independently of each other. In those cases, the UI will be using
> microphone and speaker (or headphones) anyway, to differentiate the
> input and output portions, no?
Note sure about this. While in some contexts input and output might be
distuingished for devices I think it is a good idea to not do that
unless really necessary. i.e. if you use a headset you want you phone
call input AND output go through it. While some freaks might want to
do audio playback via there USB speakers and only input via the
headset I think generally it is pretty stupid to do this. The icons
should lead the user to the obvious way to use things, not the exotic.
Also I think the main use for the icons in the audio contexts is to
help identify devices, i.e they should visualize the actual
hardware. Thus even in UIs where input and output is distuinigished it
makes sense to show a webcam icon even for the input part.
May I suggest the following names?
audio-card (as it exists right now, intended for the generic idea of 'audio')
audio-handsfree (no priority, feel free to ignore this part)
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the xdg