org.freedesktop.PowerManagement

[Holger Macht]

On Fri 30. Mar - 18:58:41, David Zeuthen wrote:
> 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.

Me too, because...

> 
>       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!

It's exactly what I have already proposed in another mail. Except that
org.freedesktop.SessionManagement was called org.freedesktop.Desktop.* in
my proposal.

Regards,
	Holger