ubuntu-phone team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Zanetti wrote on 30/09/15 13:08:
> 
> On 30.09.2015 12:59, Oliver Grawert wrote:
>> 
>> Am Mittwoch, den 30.09.2015, 12:21 +0200 schrieb Michael 
>> Zanetti:
>>> 
>>> On 30.09.2015 12:01, Oliver Grawert wrote:
>>>> 
>>>> Am Dienstag, den 29.09.2015, 18:07 +0100 schrieb Matthew
>>>> Paul Thomas:
>>>>> 
>>>>> As far as I know, nothing is preventing developers from 
>>>>> putting a role-specific slider in their apps. But that 
>>>>> doesn't/wouldn't fix any of the problems where the volume 
>>>>> buttons don't do what you expect.
>>>> 
>>>> quoting you from bug 1389761:
>>>> 
>>>> We'll add a "system volume slider" as a standard toolkit 
>>>> widget that any app can use. This slider will do three 
>>>> special things: ... (b) automatically reflect, and adjust, 
>>>> the system volume for the active output role, without the app
>>>> having to do anything at all; ...
>>>> 
>>>> did i misunderstand you in that bug ? to me it reads like we 
>>>> will have a volume slider element in the toolkit that isn't 
>>>> modifyable for the role ...  (instead of having one that 
>>>> defaults to the active role but allows a dev to override it 
>>>> with a "role: " property)

Either you can roll your own role-specific volume slider now, or you
can't. (I assume you can, but I don't know.) The introduction of a
system volume control won't alter that either way.

>>> IMHO, apps should not be able to change the system volume... 
>>> They might have a slider inside which then adjusts their own 
>>> sounds relative to the current system value, but in no way an 
>>> app should be able to change another app's volume.

It seems like a weird thing to allow, sure. But consider the
consequence if we forced all app volume sliders to be app-specific.
Instead of having two, or three, or four audio output roles, we would
now have, effectively, at least one role for each app that outputs
audio. You have ten apps installed that can output audio? You'd now
have at least ten roles.

For example, imagine you're playing a game while babysitting. While in
that game, you turn down the volume so as not to wake anyone. Later,
you switch to another game. You shouldn't have to remember to turn
down the volume for that game separately. The entire point of roles is
to save you from having to do that.

You could say, "Well, people should just use the hardware buttons for
that". But it seems like a weird limitation that your app can't
include a volume slider that behaves as people will usually expect, it
can only include one that doesn't.

> ...
> 
> fair point... It still is useful to relatively adjust things
> inside the app. For example machines vs machines does have such
> sliders. One for controlling the background music, one for
> controlling the sound effects. Those sliders are not to be
> understood as absolute volume controls, but rather as a setting if
> you want to have more background music, or more sound effects (or
> to turn one of them off completely). To control the overall volume
> of the game, use the multimedia-slider in the system.
> 
> I just have noticed that those sliders don't work at all in the 
> game any more... They used to work in the way I described at some 
> point tho... Seems the Audio {} element just ignores the volume 
> property nowadays (?). I haven't really debugged where it's going 
> wrong atm though.

This is probably "Volume obtained is 100% in multimedia sink for
sounds from app" <http://launchpad.net/bugs/1485522>.

>> what i'm trying to say is that *if* we provide a volume slider 
>> element in the toolkit, the role should be selectable by the 
>> developer, else that slider is rather useless IMHO (especially if
>> it jumps back and forth between the active roles like it does 
>> today).
> 
> ...

Whichever way the sound effect problem is solved, the role will change
much less often than it does now, so the slider will jump around much
less than it does now. (And when the alarm role is being used, often a
dialog is up so you can't interact with a slider behind it anyway.)

- -- 
mpt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlYNZEoACgkQ6PUxNfU6ecpGWwCffnOCTsDUL7YWcLW8XMO5ZPmZ
yL0An2QgeJt00hW1f6oAfyx5QCyN4wQx
=nbI1
-----END PGP SIGNATURE-----