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. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
