Created attachment 45048 [details] [review]
Adds signal arg
In Ubuntu, we got a bug filed about how suspends initiated outside of gnome-power-manager were not locking the screen correctly.
This is because it handled locking as a result of internal methods, not as a response to the Sleeping signal from upower. Ideally it would do that instead, but first, that signal needs to have enough information for a policy agent like gnome-power-manager to determine policy.
Which means it needs to tell listeners whether the sleep is a suspend or hibernate.
We received a patch for this by Phillip Susi (attached). It simply adds an int argument to the signal. Will existing dbus listeners be confused by the addition of a new argument?
Yup, see http://lists.freedesktop.org/archives/devkit-devel/2011-March/001054.html
And yes, adding an argument will upset people.
Ah, sorry, searched bugs, but didn't think about the mailing list.
What about a second signal, named "SleepingFull" or something?
SleepingFull might be best, I though perhaps Sleeping2, but both seem non-ideal. Got any better ideas?
The only alternative to a second signal I can think of is a query method like GetCurrentSleepType(), but that's a whole 'nother round trip eating into the precious second before suspend (I don't know how much of a concern that is).
Oh, I think you meant naming ideas? SleepingWithType?
(In reply to comment #4)
> The only alternative to a second signal I can think of is a query method like
> GetCurrentSleepType(), but that's a whole 'nother round trip eating into the
> precious second before suspend (I don't know how much of a concern that is).
Eek. RTT is probably too high for that. Even setting a property might be racy, I'm not sure. A PropertyChanged signal in GDBus is run in a new thread, and I'm not sure how it works when we're using the clunky dbus-glib.
At the moment I'm erring for ::SleepingKind and ::ResumingKind as we call things kinds internally (rather than type, which upsets glib sometimes).
The Sleeping signal is deprecated, and removed in my branch. We won't get a new signal.