On Fri, 2006-11-10 at 10:52 +0000, Richard Hughes wrote: > > What magic are you missing? The graphs? > > * Processor frequency scaling? > * Laptop panel auto-dimming? > * Setting low power mode (laptopmode) using HAL? > * Auto-suspend when idle? > * DPMS control? > * Configurable buttons? > * DBUS interface for other applications to use > * Inhibit and UnInhibit methods
How are all of these required in a monitoring applet? These should all be handled by the daemon. It's quite possible to run the daemon (silently) and the applet together. > g-p-m will not use the existing applet API. The new API by Ryan Lortie > looks really good and when it hits HEAD I'll experiment and see how easy > it would be to make a movable icon with text next to it in the existing > codebase. There's already a bug open. No, I would not recommend writing an applet for something like g-p-m on top of this API. I'm not sure how far along Ryan is with the new API, I'm hoping to do some experimentation and port some code over the Australian summer. To my mind, it makes sense to keep the display component as a standalone process that can be started by gnome-power-manager. There is little point in dropping all of that compatibility code, even if everyone now has HAL. If gnome-power-manager broke the display components of the daemon from the management components, then it would also become possible to write arbitrary views on top of the daemon, be it for an applet, a notification icon, a gdesklet, some kind of Hildon widget or whatever. This was always an abstraction I envisioned, allowing g-p-m to be portable in the same way that NetworkManager is. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
