david at fubar.dk
Fri Mar 30 15:58:41 PDT 2007
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
Inhibit(String app, String reason)
See  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.
 : 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
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!
More information about the xdg