[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xdg
Subject:    Re: screensaver and power manager dbus interfaces
From:       Kevin Ottens <ervin () kde ! org>
Date:       2006-06-02 10:00:37
Message-ID: 200606021200.42622.ervin () kde ! org
[Download RAW message or body]


Le jeudi 1 juin 2006 20:31, Richard Hughes a écrit :
> On Thu, 2006-06-01 at 20:10 +0200, Kevin Ottens wrote:
> To interact with the session we need this to be session context rather
> than system context.

Not sure I understood you. AFAIK, you can perfectly make calls to the system 
daemon and listen to signals... Could you be a bit more precise about the 
kind of interaction you're talking about? Is it because of the inactivity 
detection?

> Plus with David's work, the distinction between 
> session and system will be a lot smaller. For powersaved, any session
> program can just process and forward any stuff to a system daemon is
> required, as a bit of session glue is required anyway for the
> notifications and per-user config etc.

Well, that was my point. We'll end up with pure proxies and I'm not sure it's 
desirable. I'm not denying the existence of user notifications and per-user 
config, but I didn't really plan to keep them in power management specific 
daemons that would implement such a session interface...

I'll give more thought to this and maybe rework my plans. That's an 
interesting point of view difference. =)

Hence why, I won't argue more on this for the moment. Let's get a nice session 
based interface!

> I've written lots about this in the past:
> http://live.gnome.org/GnomePowerManager/SleepNames -- converting between
> one name "for developers" and one name "for users" makes everyone very
> confused when people start having problems. I'll not write more here, as
> I've explained why RAM and DISK are words we should avoid on the wiki.

Well you explained why they are words we should avoid for users. ;-)
But I see your point. I'd say we agree to disagree here, since I'm perfectly 
fine with having different terms in the GUI and in the API.

That said I can live with your proposed API, so if I'm the only one 
to "complain" about your terminology at the API level, I'll surely use it in 
my own API anyway so that we're consistent (in particular if lower level 
layers start to use it, I would be comfortable with such a compromise).

> > 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.
>
> Sounds sane, although we could go the other way and make the screensaver
> InhibitScreenSaver. Comments?

Maybe I've been unclear, I would be fine with 
InhibitInactiveSleep/UnInhibitInactiveSleep. That's the use of "Allow" there 
that disturbs me since in the ScreenSaver interface you use "UnInhibit" 
(which looks better IMHO).

I'm not requesting the Inhibit/UnInhibit pair of the ScreenSaver interface to 
be more verbose. I'm perfectly fine with the short form since the interface 
is only about one thing. Having a more verbose form in the PowerManager 
interface is required though, since you have several different concepts 
(suspend, inactivity, dpms).

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]