org.freedesktop.PowerManagement

[Richard Hughes]

On Wed, 2007-03-21 at 18:36 +0000, Rob Taylor wrote:
> Does it need a signal for the capabilities changing? e.g. if not on an
> active console, or permissions have changed?

Ahh. Valid point.

That would require signal like CanSuspendChanged and CanHibernateChanged
unless we use your bitfield thing.

> It might also make sense to just have a Capabilities bitfield rather
> than seperate calls for Suspend, Hibernate, Reboot and Shutdown. You're
> gonna call all of them at startup anyway, so makeing it one call reduces
> bus round trip considerably.

Sure, I appreciate that. Using a bit field does make the API more
complex (replying on magic constants) rather than a simple boolean
output. I'm open to doing it using a bitfield if this is common
consensus, but I must admit I like the individual API myself.

In a typical scenario, we only make 4 calls to o.f.PowerManagement to
the same interface which take a very small amount of time.

> >>> The inhibit stuff, the statistics stuff (and any other crazy random
> >>> stuff) can wait until later, I would really like to standardize on
> >>> something, so we can get some sort of standard sorted.
> >>>
> >> that's as wrong as it can get. you don't create apis which you know
> >> might become obsolete in the next extension cycle.
> > 
> > Nothing becomes obsolete, I just wanted to start small, with a core set
> > of methods and signals. We can discuss, and add to the API later when
> > the core bits are being used, without breaking anything.
> > 
> > This sort of thing is traditionally really difficult to standardize on,
> > and I don't want to make the job harder than it needs to be.
> 
> Sensible plan! The extensions can always be on a new interface.

Sure.

Thanks,

Richard.