We have moved to a new Sailfish OS Forum. Please start new discussions there.

Revision history [back]

click to hide/show revision 1
initial version

posted 2017-11-09 14:34:07 +0200

Bug: Ambiences should restore previous sound + volume when unset

Currently, Ambiences can set a new sound scheme (tones and ringer volume) when they are activated, overriding the current user preference. This in and of itself is fine and intended behaviour, but once the ambience is unset (i.e. another ambience has been activated) the previous sound scheme is not restored.

Currently, the default ambiences always force the sound scheme back to default as a workaround, however this is neither correct nor ideal since the previous/user customised sound scheme may not be the default sound scheme, and this requires the user to edit every ambience they intend to use to set their custom sound scheme, or remove all sound actions so that they at least do not clobber the user's chosen sound scheme. See also this related bug report: https://together.jolla.com/question/172783/bug-default-ambiences-should-not-set-system-tones-patch/

A quick method to demonstrate why this is a problem:

  1. Edit any ambience (besides silent) and delete the "ringtone volume" action (it is important to remember that the existence of this action in any ambience is a workaround for the issue described in this report, so it is necessary to remove it to see the problem)
  2. Make sure the ringer is set to some audible volume, e.g. 60%
  3. Activate the silent profile
  4. Activate the profile customised in step 1
  5. Note that despite the phone no longer being set to silent, the ringer volume is still set to 0%, but we expected it to have been restored to the previous audible volume of 60%

A similar issue would occur even if skipping step 1, since given the existence of the current workaround (i.e. that every ambience defaults to set the ringer to 80% volume) step 5 would have set the ringer volume to 80% instead of restoring it to the expected 60% the user had set.

The correct way to resolve this is to have the ambience daemon remember what sound scheme was set when activating an ambience, and then restore that sound scheme when the ambience is deactivated, prior to activating any sound scheme associated with the new ambience. If the new ambience does not contain a sound scheme this would stop with the prior sound scheme restored, and if the new ambience does contain a sound scheme of its own then that would be applied and the just restored scheme would be remembered for the next switch.

This implementation must also be aware that if the user has modified and of the sounds under "sounds and feedback" that these would take the place of any remembered previous setting, so that deactivating an ambience would not restore a previous setting as that would clobber the user preference, however activating a new ambience may still change the sound scheme and remember the user's changes as the previous settings for later restoration.

Bug: Ambiences should restore previous sound + volume when unset

Currently, Ambiences can set a new sound scheme (tones and ringer volume) when they are activated, overriding the current user preference. This in and of itself is fine and intended behaviour, but once the ambience is unset (i.e. another ambience has been activated) the previous sound scheme is not restored.

Currently, the default ambiences always force the sound scheme back to default as a workaround, however this is neither correct nor ideal since the previous/user customised sound scheme may not be the default sound scheme, and this requires the user to edit every ambience they intend to use to set their custom sound scheme, or remove all sound actions so that they at least do not clobber the user's chosen sound scheme. See also this related bug report: https://together.jolla.com/question/172783/bug-default-ambiences-should-not-set-system-tones-patch/

A quick method to demonstrate why this is a problem:

  1. Edit any ambience (besides silent) and delete the "ringtone volume" action (it is important to remember that the existence of this action in any ambience is a workaround for the issue described in this report, so it is necessary to remove it to see the problem)
  2. Make sure the ringer is set to some audible volume, e.g. 60%
  3. Activate the silent profileambience
  4. Activate the profile ambience customised in step 1
  5. Note that despite the phone no longer being set to silent, the ringer volume is still set to 0%, but we expected it to have been restored to the previous audible volume of 60%

A similar issue would occur even if skipping step 1, since given the existence of the current workaround (i.e. that every ambience defaults to set the ringer to 80% volume) step 5 would have set the ringer volume to 80% instead of restoring it to the expected 60% the user had set.

The correct way to resolve this is to have the ambience daemon remember what sound scheme was set when activating an ambience, and then restore that sound scheme when the ambience is deactivated, prior to activating any sound scheme associated with the new ambience. If the new ambience does not contain a sound scheme this would stop with the prior sound scheme restored, and if the new ambience does contain a sound scheme of its own then that would be applied and the just restored scheme would be remembered for the next switch.

This implementation must also be aware that if the user has modified and of the sounds under "sounds and feedback" that these would take the place of any remembered previous setting, so that deactivating an ambience would not restore a previous setting as that would clobber the user preference, however activating a new ambience may still change the sound scheme and remember the user's changes as the previous settings for later restoration.

Bug: Ambiences should restore previous sound + volume when unset

Currently, Ambiences can set a new sound scheme (tones and ringer volume) when they are activated, overriding the current user preference. This in and of itself is fine and intended behaviour, but once the ambience is unset (i.e. another ambience has been activated) the previous sound scheme is not restored.

Currently, the default ambiences always force the sound scheme back to default as a workaround, however this is neither correct nor ideal since the previous/user customised sound scheme may not be the default sound scheme, and this requires the user to edit every ambience they intend to use to set their custom sound scheme, or remove all sound actions so that they at least do not clobber the user's chosen sound scheme. See also this related bug report: https://together.jolla.com/question/172783/bug-default-ambiences-should-not-set-system-tones-patch/

A quick method to demonstrate why this is a problem:

  1. Edit any ambience (besides silent) and delete the "ringtone volume" action (it is important to remember that the existence of this action in any ambience is a workaround for the issue described in this report, so it is necessary to remove it to see the problem)
  2. Make sure the ringer is set to some audible volume, e.g. 60%
  3. Activate the silent ambience
  4. Activate the ambience customised in step 1
  5. Note that despite the phone no longer being set to silent, the ringer volume is still set to 0%, but we expected it to have been restored to the previous audible volume of 60%

A similar issue would occur even if skipping step 1, since given the existence of the current workaround (i.e. that every ambience defaults to set the ringer to 80% volume) step 5 would have set the ringer volume to 80% instead of restoring it to the expected 60% the user had set.

The correct way to resolve this is to have the ambience daemon remember what sound scheme was set when activating an ambience, and then restore that sound scheme when the ambience is deactivated, prior to activating any sound scheme associated with the new ambience. If the new ambience does not contain a sound scheme this would stop with the prior sound scheme restored, and if the new ambience does contain a sound scheme of its own then that would be applied and the just restored scheme would be remembered for the next switch.

This implementation must also be aware that if the user has modified and any of the sounds under "sounds and feedback" that these would take the place of any remembered previous setting, so that deactivating an ambience would not restore a previous setting as that would clobber the user preference, however activating a new ambience may still change the sound scheme and remember the user's changes as the previous settings for later restoration.