l.lunak at suse.cz
Sat Mar 31 01:07:26 PDT 2007
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
> 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
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
> Would this work for everyone? Personally I think this is a lot nicer.
Yes, I'm perfectly fine with the org.fd.SM interface.
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
More information about the xdg