Share ring tone with greeter via AccountsService

[Michael Terry]

(I'm not sure exactly which component will have to have code changes for this yet. I think telephony-service, so I'm starting this bug there. Feel free to change.)

The ring tone setting will have to be shared with the greeter, so it can make the appropriate sound when called. Additionally, only one session on the system should make the sound when called. Right now, I believe all open user sessions do. Only the one that is active according to logind should ring.

This will involve a change in ubuntu-system-settings to synchronize the setting when changed.

[Iain Lane (laney)]

I'll take the system-settings side of this. I'll create the AS schema and have it sync the values from GSettings to there initially. When telephony-service switches over to using AS then we can drop the syncing and stop setting the GSettings values.

There will need to be migration in place. If session-migration works or can be made to work on the phone then we should use that, otherwise telephony-service can do it - copying GSettings into AS if it's different.

[Iain Lane (laney)]

telephony-service needs to look at AS for silent mode too

session-migration needs an upstart user session job for the phone, then it works

[Iain Lane (laney)]

gnome-session should stop running session-migration if we're in an upstart session

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-session - 3.9.90-0ubuntu5

---------------
gnome-session (3.9.90-0ubuntu5) trusty; urgency=medium

  * Don't run session-migration if we're in an upstart user session as the
    session job will have done that for us. (LP: #1265528)
 -- Iain Lane <email address hidden> Thu, 09 Jan 2014 12:04:10 +0000

[Sebastien Bacher (seb128)]

Not sure we discussed that in the past, but for such configurations where we have a gsettings key synced to accountsservice, what do we consider the canonical source/configuration? is that still gsettings? (e.g what should the phone app use)

if that's gsettings, what is responsible for updating the accountsservice side when the value change (we are adding code to ubuntu-system-settings to do it, but if the value is changed by some other way (gsettings command line, phone app itself, some third party software)?
Do we expect each "client" to have that "synchronization" code?

Note that for the desktop background case on the desktop we did patch gnome-settings-daemon/nautilus to update the service, those are services running all the time, it means the configuration tools don't need to each re-implement the sync code

[Iain Lane (laney)]

On Fri, Jan 10, 2014 at 05:13:16PM -0000, Sebastien Bacher wrote:
> Not sure we discussed that in the past, but for such configurations
> where we have a gsettings key synced to accountsservice, what do we
> consider the canonical source/configuration? is that still gsettings?
> (e.g what should the phone app use)

I was working under the assumption that consumers are to be converted to
AS. The way that I've implemented this is that u-s-s is setting both
until everything stops using gsettings. Once everything (that we know
about) is converted then we should stop setting GSettings, and after a
cycle or so I guess drop the keys from the schema, although that's not
so important.

AS is a bit harder to query that GSettings is, so there might be scope
for a commandline tool like `gsettings' to deal with that. We've got a
load of ad-hoc (some patched in) properties that make this not very
attractive though.

& there should ideally be a library (there are a few floating around -
don't think any are in Ubuntu yet) to interface with AS from Qt. In the
meantime using D-Bus or the glib library directly isn't that painful.

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Sebastien Bacher (seb128)]

Hum, I'm not sure I like the idea to make AS the default configuration source.

Binding a property to a gsettings key is a 1 liner with gsettings-qt and it's quite light on resources, using AS seems quite heavier in code and less error proof to me (I trust less the AS service than dconf I guess).

That said that's just personnal feeling, but I think it's a topic worth discussing before deciding on a direction.

Michael, do you have an opinion on that? Should we maybe move that discussion to a list ?

[Iain Lane (laney)]

On Fri, Jan 10, 2014 at 05:55:06PM -0000, Sebastien Bacher wrote:
> Hum, I'm not sure I like the idea to make AS the default configuration
> source.
>
> Binding a property to a gsettings key is a 1 liner with gsettings-qt and
> it's quite light on resources, using AS seems quite heavier in code and
> less error proof to me (I trust less the AS service than dconf I guess).
>
> That said that's just personnal feeling, but I think it's a topic worth
> discussing before deciding on a direction.
>
> Michael, do you have an opinion on that? Should we maybe move that
> discussion to a list ?

Then there should be a library. Having to maintain synchronisations
everywhere is pretty bad IMO. It seems pretty obviously the right way to
go to me, but if you want to have a discussion then feel free.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Sebastien Bacher (seb128)]

@Mike: btw, you already had opened bug #1237642, do you consider that as a duplicate or do you want to keep the other ones for other settings (you mentioned e.g storing the sound level there)

[Sebastien Bacher (seb128)]

@Iain: yeah, I don't like having 2 storage and synchronization either.

I'm a bit reluctant since accountsservice was not really designed to be a config storage service and has downside compared to gsettings (no nice client API, reading involves hitting the bus and talking to a service (means relying on more code to be robust) ... I guess we should give it a try though

(bonus points if we make the telephony-service have fallback code in case something wrong happens with the config reading)

[Michael Terry (mterry)]

@seb128: I agree that AS is less good for us than gsettings in at least the following important ways:
1) it is harder for admins to change the default value of custom properties
2) there is not yet a friendly get/set command line tool
3) libaccountsservice hasn't yet added API for custom properties
4) correctly setting the permissions for properties to be only shared with the lightdm user is easy to forget to do

But on the other hand, for our "sharing info with greeter" use case, I think it's a necessary evil. As for making it more optimal: #1 can be managed with diverts, #2 can be fixed with a small amount of effort, #3 with a bit more effort, and #4 could be fixed by installing a common policykit policy that could be referenced by all custom properties that are for lightdm.

Given that storing config in AS is a necessary evil and that synchronization adds all sorts of new problems, I would prefer to avoid synchronization where possible and just use AS as the canonical store for configuration that needs to be shared with the greeter.

About bug 1237642, I did forget that I mentioned ring tone in that bug when I was filing this one. I was thinking that this bug was for ring tone and that one for volume/mute. But both ring tone and volume settings need the same treatment. If you'd like to dup one of the bugs that's fine.

[Michael Terry (mterry)]

(I would also be open to a service that does syncing for us for all greeter-related AS custom properties. But I'd like to avoid it if possible. I don't think we have an actual need for gsettings to be considered the canonical store.)

[Launchpad Janitor (janitor)]

This bug was fixed in the package gsettings-ubuntu-touch-schemas - 0.0.1+14.04.20140130.1-0ubuntu1

---------------
gsettings-ubuntu-touch-schemas (0.0.1+14.04.20140130.1-0ubuntu1) trusty; urgency=low

  [ Iain Lane ]
  * Move AccountsService vendor extension schema from ubuntu-system-
    settings.
  * Add the Sound schema (LP: #1265528). (LP: #1265528)
  * Add a key for the automatic brightness state (LP: #1273174)
  * Use current ubuntu-system-settings version to Break/Replace on as
    this is the version that will lose the AS schemas
 -- Ubuntu daily release <email address hidden> Thu, 30 Jan 2014 16:44:57 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package telephony-service - 0.1+14.04.20140303-0ubuntu1

---------------
telephony-service (0.1+14.04.20140303-0ubuntu1) trusty; urgency=low

  [ Iain Lane ]
  * Read the user's ringtone, message tone and silent mode settings from
    AccountsService instead of GSettings (LP: #1265528)
 -- Ubuntu daily release <email address hidden> Mon, 03 Mar 2014 17:13:40 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-system-settings - 0.1+14.04.20140303-0ubuntu1

---------------
ubuntu-system-settings (0.1+14.04.20140303-0ubuntu1) trusty; urgency=low

  [ CI bot ]
  * Resync trunk

  [ Iain Lane ]
  * Also store the ringtone, messages and silent mode settings in
    AccountsService. (LP: #1265528)
 -- Ubuntu daily release <email address hidden> Mon, 03 Mar 2014 17:03:35 +0000