org.freedesktop.PowerManagement

[David Zeuthen]

On Wed, 2007-03-21 at 18:27 +0100, Oswald Buddenhagen wrote:
> On Tue, Mar 20, 2007 at 09:50:20PM +0000, Richard Hughes wrote:
> > I want to restart discussion on the previously discussed session power
> > management interface: org.freedesktop.PowerManagement
> > 
> instead of restarting it you might want to choose to continue it - that
> would save us some time. ;)
> 
> you can start by processing that one:
> http://lists.freedesktop.org/archives/xdg/2006-June/008202.html
> 
> in particular, your proposal is missing a way to express "you would be
> allowed to shutdown/... if you proved to be in an authorized group
> first". of course this example is a bit narrow-minded, but you get the
> idea.

So I think the point you are missing is that implementations, the policy
managers, offering these interfaces (for example gnome-power-manager,
kpowersave etc.) will take care of this of interacting with the user and
pop up dialogs if they are not privileged to invoke the system-mechanism
[1]. 

I submit that it is the right thing that these policy managers needs to
handle cases where the operation they want to do (shutdown, suspend,
hibernate etc.) is either not available (no privilege) or fails. This is
the right thing to do because said policy managers run in the session,
have access to the display and sound devices and maintain policy
according to user preferences. 

The proposed API is _simply_ for the rest of the desktop session to
easily interact with power management policy. Hence, we want to keep the
API really simple. And thinking more about it - this is probably what we
want _anyway_; there's just no need for desktop applications using the
o.fd.PowerManagement session D-Bus API to each individually care about
handling "no privilege" and take the appropriate course of action; e.g.
put up a "enter root password" dialog. 

In fact, if we punted such implementation details to apps users would
get different dialogs from all over the place. With delegating this to
the _implementation_ of the API, the policy manager (g-p-m, kpowersave)
and so forth you actually get the native dialog (e.g. GNOME and KDE)
even if non-native apps (e.g. a GNOME app on KDE) are calling into this
interface.

Does it make more sense now?

      David

[1] : and said policy managers can be smart about these things; for
example it's somewhat futile to put up a dialog "enter root password to
suspend" or "suspend failed" if the request to suspend comes from an
event where the user closes the laptop lid (and the user preferences
asks for this action). 

In this event the right thing for that policy manager is probably to
play a loud sound to alert the user that suspend is not going to happen.