David Zeuthen david at
Wed Mar 21 19:18:34 PDT 2007

On Wed, 2007-03-21 at 19:26 +0000, Richard Hughes wrote:
> That's not the job of a session power management interface. You're not
> going to present to the user:
> ===== Suspend ======
> You have not got the permissions to suspend
> Enter root password: [_______________]
> As that would be madness. Either the user can suspend or not.

That's your opinion, it's a constraint I personally share and I guess
most of us do. But there is strictly no need to force that constraint
upon others because I don't think we need to. If a policy manager really
wants to present such a dialog it should be free to do so. The point
here is that it's up to the _implementation_ of org.fd.PowerManager to
do this in response to the events it cares about, e.g. 

 1. lid close event
 2. session inactivity
 3. user specifically pressed a hotkey
 4. user specifically pressed a graphical button in the UI
 5. some app called into Suspend() on org.freedesktop.PowerManager on
    the D-Bus session bus interface

Clearly, a good implementation (like g-p-m or kpowersave) have logic to
actually determine whether it's useful to put up the dialog; e.g. for
events from sources 1. and 2. it just doesn't make sense, for source 3.
and 4. it might and for 5. it probably might as well. 

As such, we need to clarify that _implementations_ of the interface
org.fd.PowerManager *may* initiate user interaction in response to
certain method calls. As a corollary, the docs for said method calls on
the org.fd.PowerManager interface should state that apps *must* only
call this method in response to user action. 

And this is fine; there is no need for calling these methods in response
to any event that does not originate from user actions since the policy
manager itself should handle all the other events (e.g. lid presses,
hotkeys, session inactivity, other sources).

(To be compliant e.g. the GNOME panel calls _only_ calls Suspend() when
the user selects the System->Suspend menu item. Which is how it works


More information about the xdg mailing list