org.freedesktop.PowerManagement
Richard Hughes
hughsient at gmail.com
Thu Mar 29 08:25:51 PDT 2007
On Thu, 2007-03-29 at 17:24 +0200, Holger Macht wrote:
> On Thu 29. Mar - 16:08:05, Richard Hughes wrote:
> > On 29/03/07, Holger Macht <hmacht at suse.de> wrote:
> > >1. Shouldn't we add a "time until wakeup" argument to the suspend call? I
> > > imagine a vcr application calling suspend with this argument to wakeup
> > > and start recording. Yes, something we can add later on.
> >
> > Yes, but I don't know a single laptop this works correctly for. You
> > could argue the same about Standby, Hibernate and Shutdown. Maybe
> > another method TimedSleep or something?
>
> Isn't it possible to define optional arguments?
With the raw DBUS I think yes, but using the bindings no, if I
understand correctly.
> > >2. You are calling one section "compulsory basic interface". So in case
> > > you don't have a real power management application such as g-p-m or
> > > kpowersave on the desktop, but of course still need the shutdown and
> > > reboot interfaces, someone else (the desktop base) has to implement all
> > > of the others too? That seems unfeasible to me. Or am I getting
> > > something wrong here?
> >
> > Hmm. I figured they could all be just stubs that return NoHardware or
> > PermissionDeniedByPolicy or something like that. Maybe an error of
> > NotImplemented should be added to the spec. A stub in python is only a
> > few lines of code, and then we stop lazy XFCE (joke!) people from not
> > implimenting the whole base spec.
>
> NotImplemented would be the only correct return value, but from my point
> of view, the interfaces wouldn't be compulsory anymore ;-)
Point taken. NotImplemented should be added the the 0.2 spec anyway IMO.
> I thing it has to be split and staggered in a more detailed way to become
> sensible because shutdown and reboot have an exceptional position and must
> be treated in a different way.
How do you mean split? You mean say that Shutdown() is optional but
Suspend() is compulsory?
Richard.
More information about the xdg
mailing list