l.lunak at suse.cz
Fri Mar 30 15:08:18 PDT 2007
On pá 30. března 2007, David Zeuthen wrote:
> On Fri, 2007-03-30 at 23:19 +0200, Lubos Lunak wrote:
> > but if you
> > want: Shutdown/Reboot are basic functionality but power management
> > features are an add-on that not everybody may be interested in having
> > (see above for my feedback on that part). Since a DBUS interface cannot
> > be split that makes the whole org.fd.PM interface optional and therefore
> > Shutdown/Reboot should not be part of it.
> 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?
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