org.freedesktop.PowerManagement
Holger Macht
hmacht at suse.de
Thu Mar 29 15:21:07 PDT 2007
On Fri 30. Mar - 00:12:55, Danny Kukawka wrote:
> On Freitag, 30. März 2007, Holger Macht wrote:
> > On Thu 29. Mar - 22:58:10, Richard Hughes wrote:
> > > On Thu, 2007-03-29 at 23:52 +0200, Holger Macht wrote:
> > > > I don't why it's only me seeing the problem here? You want to have
> > > > Shutdown() and Reboot() on _every_ system, but not mandatory the other
> > > > methods. If you don't have a pm application providing "the other"
> > > > methods,
> > > > you need to implement them somewhere else to meet the spec's
> > > > requirements. And that seems wrong to me. If you need to implement
> > > > them a
> > > > second time, you could do it right at the one place where you need
> > > > them
> > > > compulsory, the desktop base. You won't need a pm app then.
> > >
> > > I don't think you need to define the o.fd.pm interface in the desktop
> > > base. I think saying "at least something will provide o.fd.pm" is good
> > > enough; for instance:
> > >
> > > XFCE can just build the interface into the base session layer with a
> > > thin wrapper around HAL
> > > GNOME can use gnome-power-manager
> > > KDE can use kpowersaved or guidance-power-manager
> >
> > I'm talking about a GNOME or KDE _without_ gnome-power-manager or
> > kpowersave.
>
> IMO this is something the desktop and not a powermanager should implement.
> KPowersave for example also don't call HAL to Shutdown, it call simply KDE to
> handle this (via DCOP and in KDE4 IMO via DBus).
Good point. For system sleep, the pm app knows best how to prepare this
tricky thing. So Suspend()/Hibernate() is generally located there. For
shutdown, and thus saving the session, saving all unsaved documents,
etc. the desktop base itself should know best. So the method should got
there. It might be clever to let Suspend()/Hibernate() be implemented by
the pm app and Shutdown()/Reboot() by the desktop base. That wouldn't be
possible with this spec IMO.
Regards,
Holger
More information about the xdg
mailing list