org.freedesktop.PowerManagement
Holger Macht
hmacht at suse.de
Thu Mar 29 15:25:14 PDT 2007
On Thu 29. Mar - 18:21:32, David Zeuthen wrote:
> On Fri, 2007-03-30 at 00:03 +0200, 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.
>
> Am not really sure where we disagree. I mean, GNOME ships with
> gnome-power-manager in the release set, so GNOME is good out of the box.
People want to disable gnome power manager on usual desktop systems.
> I think if KDE doesn't ship with kpowersave (or something else), you
> want to tell the KDE people to at least provide _something_? Ditto for
> other desktop environments. The desktop in question may choose to punt
> this to the distribution.
Yes, and I'm arguing that if for whatever reason, one doesn't like to ship
or use "something", you still should have Shutdown() and Reboot(). So
these two methods should not depend on a power management interface.
Regards,
Holger
More information about the xdg
mailing list