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

[Richard Hughes]

On 21/03/07, Alp Toker <alp at atoker.com> 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.