org.freedesktop.PowerManagement

[Lubos Lunak]

On so 31. března 2007, David Zeuthen wrote:
> On Sat, 2007-03-31 at 00:08 +0200, Lubos Lunak wrote:
> > Or do you have more reasons besides Inhibit() that'd require
> > shutdown/reboot to be in the power management interface?
>
> Not really; personally I'd like to get rid of them but the point about
> that if a caller inhibits the PM interface it should inhibit the
> Shutdown/Logout/Reboot interface as well. It seems you are suggestion
> two specs then:
>
>  org.freedesktop.PowerManagement - but without Shutdown() and Reboot()
>
> and this one
>
>  org.freedesktop.SessionManagement
>    Shutdown()
>    Reboot()
>    Logout()
>    Inhibit(String app, String reason)
> The way this could work is then that org.fd.PM.Inhibit() would also call
> Inhibit() on org.fd.SM.

 Session management does not have any Inhibit( app, reason ), that's not how 
it works. If you edit a file in a text editor and it needs saving, then 
during logout the app gets a message, it sees the file needs saving, it asks 
the user and depending on the answer from the user it either allows the 
logout to continue or it cancels it. I don't quite see how you'd want to 
match such behavior to Inhibit(). It could however be handled by the 
component providing org.fd.PM registering with XSMP and cancelling the logout 
when inhibited (I think somebody has already suggested this elsewhere in this 
thread).

 I'm still not quite sure Inhibit() even belongs to PM interface, I cannot 
think of a single case when an app would want to block suspend but would not 
want to block logout, so it'd always have to block both of them. However the 
SM semantics (at least as they're in XSMP) wouldn't allow blocking PM suspend 
by blocking SM logout. Not that I have any better idea.

> Specifically, as you mention, existing PM 
> daemons like gnome-power-manager, kpowersave etc. would just provide
> both "interfaces" until something better comes along to provide
> org.freedesktop.SessionManagement, e.g. for GNOME it . Notably we can
> extend this interface later on.

 Yes. A session management providing merely shutdown/reboot/logout is vastly 
insufficient and would basically just use the XSMP-provided functionality 
(plus whatever starts the shutdown/reboot afterwards). I originally suggested 
the org.fd.ShutdownManagement name because of this but if this is meant to be 
extended somewhen in the future than I think it can be called 
org.fd.SessionManagement.

> Would this work for everyone? Personally I think this is a lot nicer.

 Yes, I'm perfectly fine with the org.fd.SM interface.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz