[Kde-hardware-devel] org.freedesktop.PowerManagement

Alp Toker alp at atoker.com
Wed Mar 21 13:31:00 CET 2007


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.)


</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.


<!--
  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.


<!--
  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.


Anyway, it's great that you're calling for public review of this API -- 
other developers need to learn from this process.


More information about the Kde-hardware-devel mailing list