screensaver and power manager dbus interfaces

[David Zeuthen]

On Wed, 2006-05-31 at 23:01 +0100, Richard Hughes wrote:
> Okay, my first post to this list, so I hope I'm aiming in the right
> direction.
> 
> gnome power manager :		org.gnome.PowerManager
> gnome screensaver   :		org.gnome.ScreenSaver
> 
> This should probably be cross desktop and less gnome-y as there's no
> reason another program shouldn't just drop in as a replacement for
> either xfce, kde or just a slim-line gnome replacement.
> 
> The interfaces we have now are attached.
> 
> Comments appreciated.

Thanks for posting this Richard. As a data point, these interfaces and
the software that currently implements them (gnome-power-manager and
gnome-screensaver) are already in use in a number of distributions that
ship GNOME 2.14 and from what I can it appears to work well.

There's a couple of things I'd like to see these interfaces do that is
not already there. Such as allowing applications to delay the suspend
such that they can synchronize state and release resources [1]. I'm sure
we can add this along the way, let's get the basics done first.

I'd also like to hear input from people doing applications running on
embedded systems as such systems have pretty harsh power management
requirement. Ideally all that any applications need to do wrt. power
management should be covered by these interfaces.

Finally, I like what Waldo is proposing about standardizing on an
org.freedesktop name space. I'm hoping we can come to an agreement on
this for use on all free software desktops and then freeze the spec.

I think I only have one comment on the current spec:

>         Name:           Inhibit
>         Args:           DBUS_TYPE_STRING "application-name"
>                         DBUS_TYPE_STRING "reason for inhibit"
>         Returns:        INT cookie
>                         This is a random number used to identify the request.
>         Description:    Request that saving the screen due to system idleness
>                         be blocked until UnInhibit is called or the
>                         calling process exits.

This is already very accurate, but it might be useful to clarify exactly
what this means through a few examples. 

For example, the PowerManager SHOULD ignore applications using Inhibit()
if e.g. the user is closing the laptop lid. The Power Manager SHOULD
prompt the user if user is trying to suspend while an app is using
Inhibit() and the screen is still visible. 

Stuff like that; I think it might be useful with a few MUST and SHOULD
clauses to guide implementors of these interfaces in the same direction.

Cheers,
David

[1] : an IRC client might want to sign off all channels with the message
"User's computer is going to sleep"; an email client might want to
synchronize email headers to update the IMAP server; things like that.