org.freedesktop.PowerManagement

[David Zeuthen]

On Sat, 2007-03-31 at 00:08 +0200, Lubos Lunak wrote: 
> > The problem here is that Inhibit() on org.fd.PM affects the
> > implementation on of Shutdown() and Reboot() - e.g. if I want to be able
> > to make sure that the user gets this dialog
> >
> >  Some app $APP is preventing shut down because: $REASON.
> >
> >                                [Cancel] [Shut down anyway]
> >
> > where $APP may be "k3b" and reason may be "burning DVD". Don't you want
> > this kind of interaction?
> 
>  I do and I can have it - in session management. In fact, should have it. Just 
> logging out would stop the burning as well, so if there should be any such 
> warning with suspend, there should be with logout as well.
> 
>  And shutdown/reboot imply logout, while suspend does not. Which means I can 
> have the warning for free and it can be also counted as another reason that 
> shutdown/reboot are a bit different from power management and as such don't 
> quite fit in power management interface.



> 
> > And if you care about memory consumption no-one is forcing you to run
> > g-p-m or kpowersave; just run other stuff instead and make it return
> > NotSupported for anything anything but Shutdown() and Reboot(). That's
> > not really too much to ask I think. Thoughts?
> 
>  That other stuff would probably have to be the desktop itself, since there 
> should always be a way to shutdown/reboot. Which means the desktop would 
> somehow have to detect presence of a power management daemon and in the case 
> of absence of it it'd have to provide the interface, or it'd have to provide 
> the interface by default and hand it over to the daemon if needed, or 
> whatever. IMHO ugly, if nothing else. Having two interfaces and g-p-m taking 
> care of both looks much simpler, given they can be independent. 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)

See [1] for discussion on nomenclature.

The way this could work is then that org.fd.PM.Inhibit() would also call
Inhibit() on org.fd.SM. 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.

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

      David


[1] : Note that these are really two different D-Bus name; it's not a
problem but when we say "interface" we really mean the (D-Bus service,
D-Bus object, D-Bus interface) tupple. For this example it's

D-Bus name:      org.freedesktop.PowerManagement
D-Bus object:    /org/freedesktop/PowerManagement
D-Bus interface: org.freedesktop.PowerManagement

and

D-Bus name:      org.freedesktop.SessionManagement
D-Bus object:    /org/freedesktop/SessionManagement
D-Bus interface: org.freedesktop.SessionManagement

Just trying to make it clear. Hope it's not too confusing!