[pulseaudio-discuss] Standardising on the amount of software amplification is presented to the user

[Tanu Kaskinen]

On Wed, 2010-04-14 at 10:18 +0100, Colin Guthrie wrote:
> 'Twas brillig, and Tanu Kaskinen at 13/04/10 20:42 did gyre and gimble:
> > Solution: throw away volume sliders in applications, and promote
> > centralized volume management with volume applets and hardware controls.
> 
> Even if this is the right solution[1], it would take a very long time to
> a) convince application developers this was the cases, and b) develop
> the GUI changes etc needed to implement this.

About a): if we agree that volume sliders are generally a bad thing in
individual applications, we should push removing the sliders whenever we
discuss volume control functionality with application developers. In
case they reject the radical change (or we expect them to), we can
additionally give recommendations for what's the best way to handle
volume sliders. So don't take this as criticism for your proposal - I'm
only pointing out that if we see removal of volume sliders as the best
solution, we should also promote it as the best solution when
communicating with app developers.

About b): if you're talking about the development effort of removing the
sliders, I don't think it's really that much work. But I think volume
applets and hardware volume control handler software aren't as good as
they could be, and they really should be good if they're to be the only
way of changing volume in most cases (in addition to pavucontrol and
other such applications that really are too clumsy for everyday use).

But do even we, the pulseaudio community, agree on this?

> Whereas just getting the volume range right is relatively simple. I'd
> rather work under the impression that we'll be sticking with in-app
> volume controls for some time to come and get it right, and if/when it's
> decided that in-app volumes are not needed then the code can be changed
> again. I don't think the work just now would be wasted for the 2 or 3
> years it'll likely be used for if your preferred outcome does come to pass.

I agree, it's not waste of time.

> [1] I'm not entirely sure I agree for all applications - e.g. mplayer is
> a full screen app with no gui - there are keybinding for volume and it's
> awkward for me to control a separate GUI due to it being full screen
> etc. There are plenty other use cases where in-app volume control of
> some sort is very desirable.

You can toggle fullscreen by pressing F, right? I don't personally think
that switching temporarily to windowed mode and using the volume applet
is too awkward. Besides, changing the stream volume is still the wrong
thing to do (except in the rare occurrence when you actually do want to
change the volume relative to other apps). Is mplayer any different from
e.g. Totem in this regard, btw? The lack of a gui doesn't seem relevant,
except when listening to music in the console while trying to fix X, in
which case volume control in mplayer makes a lot of sense. But even then
I think controlling the device volume would be more appropriate.

Can you give some examples of the other use cases? I'm sure there are
such cases, but none comes to my mind right now.

-- 
Tanu Kaskinen