screensaver and power manager dbus interfaces

Kevin Ottens ervin at
Thu Jun 1 21:10:49 EEST 2006

Le jeudi 1 juin 2006 00:01, Richard Hughes a écrit :
> 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.

In the following I'll assume that you expect the "org.gnome.PowerManager" to 
be implementer by a session daemon since that's what g-p-m is. Although I 
fully understand the need for a session daemon regarding screensaver, I'm not 
sure I like the idea of a per session daemon for power management. I guess it 
came from the fact that you started this as a desktop specific project, but 
if we're going further with such a spec, wouldn't it be better to consider it 
implemented by system daemons (HAL, powersaved, or something else)? Otherwise 
I feel that we'll end up with almost empty session daemons simply relaying 
calls to a system daemon with more privileges... Moreover, since David hinted 
about delaying the suspend, it looks more difficult to synchronize correctly 
with several session daemons than with a single system one.

Maybe I'm missing something obvious here, so feel free to enlighten me in 
order to make my concerns on this go away.

That said, it's definitely a good idea to have well defined interfaces for 
both service types. It would make both ISV and desktop developers life 

Comments on the interfaces themselves follow.

> The interfaces we have now are attached.
> Comments appreciated.

First of all, I agree with Waldo that at one point we'll have to 
s/gnome/freedesktop/ in those specs.

- PowerManager

I'm not sure I like the "Suspend", "Hibernate", "CanSuspend", "CanHibernate" 
naming. Although it makes sense to use such metaphors for the GUI, I'd expect 
the API to state exactly what it does. So using SuspendToRam, SuspendToDisk 
and Standby (which is lacking currently, but afaik it's not really used so 
that's not really a problem I guess) would make me happier.

Regarding "Shutdown", I'm wondering if it's companion "Reboot" should be in 
the interface too?

- ScreenSaver

Regarding "Poke", well I like the name, but I'm not sure its use is obvious. 
From David description is it really meant to be used _only_ when we resume 
the system? I assume the answer is yes since for other use cases (mainly 
video playing) inhibit should be used I think. Maybe keeping the name as is 
but completing the description would be enough? In particular it might be 
useful to point to the inhibit methods, using "Poke" instead of those methods 
looks like a natural pitfall.

- PowerManager + ScreenSaver

You use InhibitInactiveSleep/AllowInactiveSleep in PowerManager, and 
Inhibit/UnInhibit in ScreenSaver. Maybe it would be better to choose one 
pair. I'd personally prefer Inhibit/UnInhibit everywhere.

More generally regarding the inhibit related methods in both interface, I 
think the descriptions should be made a bit more clear on the constraints 
imposed on the implementation. In particular the fact that it must rely on 
D-Bus disconnect to clean the cookies of crashed applications. That would 
surely remove some concerns of developers using the interface (as we already 
seen in this thread).

That was my 0.02€.

Kévin 'ervin' Ottens,
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : 

More information about the xdg mailing list