Merge lp://staging/~mterry/indicator-sound/greeter-volume into lp://staging/indicator-sound/14.04

PASSED: Continuous integration, rev:426
http://jenkins.qa.ubuntu.com/job/indicator-sound-ci/101/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-amd64-ci/41
    SUCCESS: http://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-armhf-ci/40
        deb: http://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-armhf-ci/40/artifact/work/output/*zip*/output.zip

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/indicator-sound-ci/101/rebuild

PASSED: Continuous integration, rev:427
http://jenkins.qa.ubuntu.com/job/indicator-sound-ci/102/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-amd64-ci/42
    SUCCESS: http://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-armhf-ci/41
        deb: http://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-armhf-ci/41/artifact/work/output/*zip*/output.zip

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/indicator-sound-ci/102/rebuild

I think we should change a few things here.

* I think that a better way to detect if we're on the greeter or not is to check which user we're running as. Just checking to see if a name is owned could get messed up pretty easily. It also means we don't have a race with dbus getting the name owner ever. We know our username at start.

* I'd like to see the accounts service support use the accounts service lib. It seems like a better solution.

* I'd like to see the greeter interface as an object. Vala makes this pretty easy, and it's much better than calling the dbus connection directly.

For the last two I think the easiest way to do them might be to base your branch on:

https://code.launchpad.net/~ted/indicator-sound/greeter-control/+merge/209338

Which sets those up already.

As discussed on IRC, I don't want to check username because the greeter user is a sysadmin-configurable option. But I can check an environment variable that LightDM sets that can tell us if we are in greeter. That's done.

I made the greeter interface an object.

But on using accounts service lib or a vala interface object for AccountsService, I'm going to give soft pushback. The lib isn't async nor can vala interface objects expose async property getter/setters. And since this is in UI code (like, this code is run when the user moves the volume control), I don't think making sync calls is appropriate.

PASSED: Continuous integration, rev:430
http://jenkins.qa.ubuntu.com/job/indicator-sound-ci/113/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-amd64-ci/53
    SUCCESS: http://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-armhf-ci/52
        deb: http://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-armhf-ci/52/artifact/work/output/*zip*/output.zip

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/indicator-sound-ci/113/rebuild

The actual variables would still have to be accessed through a DBusProxy, the part that the account service API would give you is the object path to the user object.

Yeah, but getting (A) the main Manager proxy and (B) asking it for the object path are both sync operations in the library API.

And once you have the object path, Vala doesn't let you perform async get/set with DBus object properties. (We could define a DBus interface for the org.freedesktop.DBus.Properties interface and use Get()/Set() directly, but that's not buying us much.)

So all in all, I agree it would be prettier code, but we'd be giving up too much.