hmacht at suse.de
Fri Mar 30 16:04:31 PDT 2007
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
> 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.
Me too, because...
>  : 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!
It's exactly what I have already proposed in another mail. Except that
org.freedesktop.SessionManagement was called org.freedesktop.Desktop.* in
More information about the xdg