On 21/03/07, Alp Toker <[EMAIL PROTECTED]> wrote: > Richard Hughes wrote: > > I've attached a draft interface and attached it to this mail. I've also > > cc'd in more people in a hope to get more responses. > > You should probably inline the XML in your mail to get people commenting > on the specifics. > > (I'm reviewing this from an API consumer point of view rather than as a > hardware guy.)
That's exactly what I had hoped for, cheers. > </method> > - > <!-- > Returns the system AC state, i.e. if we are not running on battery > power. > Note: This method may still return false on AC using a desktop > system > if the computer is using backup power from a monitored UPS. > --> > - > <method name="GetAcState"> > <arg type="b" name="ac_state" direction="out"/> > </method> > > AC (alternating current?) is kind of an implementation detail. I will > probably just want to know if the device IsOnExternalPower or something. > "AC" means nothing to me as an application developer. Valid point. What about IsOnBatteryPower? > <!-- > Returns the icon name used as the applet or status tray icon. > --> > - > <method name="GetIcon"> > <arg type="s" name="icon" direction="out"/> > </method> > > This method call looks out of place. Everything else in the API is > non-presentational. Dealing with icons and layout at a higher level will > increase the shelf life and portability of the API. Normally I would agree with you, but if we don't express the UI, then we have to export everything about all the power devices, i.e. we have to abstract HAL (pun intended). This is something I do not want to do. As we are running in the session we have the correct locale, and as implimentations between KDE and GNOME will be different (according to what the users want and how many preferences to choose from) so I think it's valid to expose this UI detail. Imagine something like the OLPC machine that justs wants a tiny widget to display an icon after querying state, and you'll appreciate that we don't want the widget to do too much work. If we are also putting the battery state in stuff like gdm, this has to be done in the session service. > <!-- > Signals the value of the current brightness has changed. > --> > <signal name="BacklightBrightnessChanged"/> > <!-- Signals the AC state has changed. --> > <signal name="AcStateChanged"/> > <!-- Signals the low power mode has changed. --> > <signal name="LowPowerModeChanged"/> > - > <!-- > Signals the system state description has changed. > --> > <signal name="DescriptionChanged"/> > <!-- Signals the system icon has changed. --> > <signal name="IconChanged"/> > > Each of these signals should include the new value following the change > to reduce round-trips. Sending out a signal just to trigger another > bunch of method calls which query the new value is kind of pointless. Yes, what you suggest is exactly what I intended, sorry for the confusion. The dbus-glib introspection format seems to ignore the return parameter of a signal if you specify it, but I'l add it to the file for next time for clarity. > Anyway, it's great that you're calling for public review of this API -- > other developers need to learn from this process. Well, the aim is to do the same for the screensaver API. It would be great to all be using the same stuff on OLPC, Maemo, KDE, GNOME etc. Again, thanks for the feedback. Richard. _______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
