On Wed, 2015-10-21 at 09:35 +0530, Arun Raghavan wrote: > On Tue, 2015-10-20 at 09:55 +0200, Wim Taymans wrote: > > > > > > On 20 October 2015 at 06:53, Arun Raghavan <arun at accosted.net> wrote: > > > On Mon, 2015-10-19 at 16:38 +0200, Wim Taymans wrote: > > > > > > I think this option is more or less the same as disabling flat > > > volumes. > > > The user is back to having at least two actions to control volume > > > (either app slider and panel slider, or open panel and adjust app > > > slider). > > It is, it would disable flat volumes by default. But it would allow > > you to enable them again for the streams you want. > >  > > >  > > > The point of flat volumes was that if you're using the application > > > volume slider, you don't need to hunt for two volume sliders to > > > adjust > > > to get the full range of volume that your hardware allows. To my > > > mind, > > > your proposal makes sense as an alternative to what I suggested > > > only if > > > we move to a model where we suggests applications do _not_ have > > > volume > > > sliders at all, and then design the desktop UX differently to > > > provide a > > > single-action way to adjust volumes. > > > As an example, the shell could track what the current playing > > > stream is > > > based on the foreground application and volume controls (hardware > > > and > > > panel mixer) could track that volume and apply changes as flat > > > volumes. > > > So the user is always only dealing with one control, by default. (I > > > just thought of this, so probably needs to be fleshed out to make > > > sense, or maybe it doesn't at all.) > > This is an interesting idea. Because the slider is part of the shell, > > we can trust it to be user-controlled and thus give is access to the > > flat-volumes of > > the stream. It's like the slider from the current app in the mixer > > appears in the shell task bar. > > > > In any case, this would work nicely with this proposal and since you > > would remove the volume from the apps, making all app-controlled > > volumes relative would be a good default. > > This is a pretty big change, though, and it's unlikely we're going to > get all desktop clients to make the switch in the near future. I think > a good way to stage these changes is to first go ahead with the per > -stream flag and let flat volumes be on by default. > > If GNOME (and/or other desktop environments) want to try the > alternative global slider, we should be able to easily figure out a > mechanism to allow them to do this (the mechanism for blacklisting can > be reused, as an example). > > If we decide that this is the model we want most desktops to work with, > we can move towards making this behaviour the default. > > Does that make sense as a way forward? I didn't really understand what the proposal was, but tracking which application is active in the shell doesn't sound good. It sounds like the global volume slider in the shell would change the application volume. I quite like my current setup: no flat volumes, and the global volume slider changes the device volume. I never use per-application volumes (except in a very niche use case, when I want one stream to play to the left speaker and another to the right speaker), so tracking down two volume sliders isn't a problem for me. If the proposal is to use role volumes, like is done in various Maemo- derived OSs (and possibly others too, but I'm not familiar with them), where there is one slider for phone volume, a few for different kinds of notification and UI sounds and one for everything else, and the global slider controls one of them according to the context, then that sounds somewhat usable. -- Tanu
