Don't show the volume overlay when changing the volume with the slider

Going to mark this as a "dup" because the indicator-sound part of this is fixed, but it now needs U8 support. Fix Released doesn't make sense as it still doesn't work.

After discussion with Charles Kerr, I'm unmarking this duplicate. Bug 1398888 cites <https://wiki.ubuntu.com/SystemComponents#Root_Item>, which doesn't mention sound volume at all, so I don't see how it can be related.

So, here's the plan.

We'll add a "system volume slider" as a standard toolkit widget that any app can use. This slider will do three special things:
(a) use standard volume icons by default;
(b) automatically reflect, and adjust, the system volume for the active output role, without the app having to do anything at all;
(c) suppress volume change notifications (but not primary sound output change notifications) whenever it is present in the active window. (But not, for example, when it is in a window behind the active window.)

The sound menu should use this slider, fixing the problem that redundant volume notifications come up with the current slider.

System Settings should use this slider, fixing the problem that redundant volume notifications come up with the current System Settings slider.

And any music player, for example the Music app, should use this slider too. An app should be able to customize its appearance, while still getting its behavior for free.

One drawback of this plan is that it won't fix bug 652978: it won't suppress notifications for track changes.

On Thu, 2015-07-30 at 15:27 +0000, Matthew Paul Thomas wrote:

> After discussion with Charles Kerr, I'm unmarking this duplicate. Bug
> 1398888 cites <https://wiki.ubuntu.com/SystemComponents#Root_Item>,
> which doesn't mention sound volume at all, so I don't see how it can be
> related.

The sound indicator does suppress the notification when it is shown, it
isn't told that it is shown today by unity. If it was told correctly, it
would suppress them. So the issue isn't the suppression, that works, it
is that Unity doesn't tell us when it is showing the menu.

> (b) automatically reflect, and adjust, the system volume for the active output role, without the app having to do anything at all;

i dont think that works, the item should have a way to select for which role you want the volume change since we auto-change roles all the time. what if a notification goes off while the app is open ? you will suddenly adjust the notification volume. what if your app uses a certain role that only gets activated if you actually play a sound.
my alternate webapp container framework allows to enable haptic feedback and click sounds for links in websites, if i enable that i can see the volume indicator jump to full volume for the lenght of the sound. if i would want to provide the mentioned slider to adjust the sound effect volume it would always only point to the main system volume unless the effect is played.
the toolkit widget should have a field to define the type of role you want it to change.

I thought I was so clever in thinking of this idea, then I researched and discovered that it's what iOS already does. <https://developer.apple.com/library/ios/documentation/MediaPlayer/Reference/MPVolumeView_Class/index.html>

> The sound indicator does suppress the notification when it is shown

On the PC it does, but not on the phone. And if it's not obvious enough even for Canonical engineers to do it, that bodes ill for app developers. With this scheme, they get the notification-suppressing behavior for free whenever they choose the easy way of embedding a volume control.

> what if a notification goes off while the app is open ? you will suddenly adjust the notification volume.

Yes, that's a drawback. But then, a notification probably should temporarily quieten media playback, so changing the media volume wouldn't be that meaningful during those few seconds anyway.

hmm, you don't seem to understand... unless i have an app that constantly plays back something (game or music player) the role used to play back my sound is never activated. in case of sound effects in an app the volume control points 99% of the time to the main system volume, not to the role your app uses to play back the effect. if your slider adjusts "the active output role" it will always adjust the main volume, not the volume of your sound effect.

to visualize what i mean, perhaps do the following:
* install the OMGUbuntu app
* turn the main volume down so that the indicator icon just doesn't show any of the curved lines in front of the speaker icon (30% or so)
* open OMGUbuntu
* keep your eyes on the indicator icon and tap a link/photo/etc in the app (that generates a sound effect)

you will see the volume jump to full volume the moment the effect plays back, your role just changed.
if the app had a slider in its settings for controlling the effect volume this slider would never control the volume you actually want to control, unless the slider element has an option to define it (this element can indeed default to the currently active role if unset, but unless you actually want the main control or unless your app constantly produces sound you would want a way to override this default to point to the correct knobs suited for the application)

Oliver, you seem to be describing bug 1478506, where either the volume UIs are showing the wrong output role most of the time, or apps are using the wrong output role by default. If it turns out to be a problem with the volume UIs, it would have been easier to fix if (nearly) all of them were using a toolkit volume slider than it is now when they're all doing their own thing.

if you refer to indicator-sound with "volume UI" then yes ... note that the apps i mentioned above only use the implementation from https://developer.ubuntu.com/api/apps/qml/sdk-15.04/QtMultimedia.SoundEffect/ ... the role changes from the default immediately when the play() function is used, and stays changed for the duration of the sound.

it might be that either our interfacing of the toolkit with the back end is broken here or the back end behaviour itself is wrong, but this kind of supports the fact that making a UI element pick the "current default" without the ability to override is the wrong approach.

what if i want to write an app that explicitly allows modification of different volumes for different roles, i would have no way to use your slider item at all but would have to completely create custom sliders, since all of yours would forcefully just point to the default output. whatever we have in the toolkit should offer to define the role it controls (with a sane default when undefined).

all i'm asking for is a way to override the default behaviour in the toolkit element, or if needed there could be a "default volume slider" and a "customizable volume slider" if you prefer to not have it in the same element.

Is "role" here the same as "category" in the Qt API? https://developer.ubuntu.com/api/apps/qml/sdk-15.04/QtMultimedia.SoundEffect/ If so, does this apply to the use case of a game that has "Music" and "Effects" sliders? A way to specify that would be required to make this slider usable for games.

Specification updated. <https://wiki.ubuntu.com/Sound?action=diff&rev2=172&rev1=171>

I would like to add a note to this bug.

I've been testing on the desktop and the OSD notification is not coming neither from the sound indicator when I change the volume using the keyboard short-cuts.
A very quick test for this I did was to be sure that the indicator was not running on the system and use the keyboard short-cuts. I still get the notification, so we cannot control that case either from the indicator.