Tanu Kaskinen schrob:
> 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.
>
> 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?
As long as there's no way to change the volume of "the current
application" via the command line (so I can teach it to my window
manager), I most certainly disagree. And yes, I do need per-application
volume control (or think I do, see below).
> 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.
It assuredly is for me. Volume control (or any important functionality)
needs to be within easy reach, i.e. 2 keypresses max. The 5+ you suggest
(includes switching back) is much too cumbersome.
> 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).
How's that rare? Most of my touching volume sliders is caused by playing
media that's not properly normalized/replaygained, or me wanting to
listen to it at above/below normal level. If I did that with the master
volume, I'd move my email/IM notification sounds as well. Or am I somehow
mistaken in using the master volume as the adjust-for-ambient-noise-slider,
and adjusting everything else per-stream to comfortable levels?
> 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.
How's being in X or not relevant? ;) If you want to stop applications
from bringing their own volume controls, you MUST provide an easily
scriptable volume control interface. Which has no reason to require X.
> 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.
Anytime you present multimedia content with a beamer or the like. You
don't want to present the volume control applet you happen to use. You
want your presentation going on and a minimal user interface for
adjusting the sound, ideally unnoticed by everyone else.
So the way forward should probably be:
1) Educate app authors about how to write _good_ embedded volume
controls.
2) Get better external volume control programs.
[time passses]
3) Convice app authors their embedded controls aren't necessary anymore.
...particularly as 3) should become a lot easier after 2) is achieved.
regards,
Jan
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20100416/9dd8e136/attachment.pgp>
