screensaver and power manager dbus interfaces

[Holger Macht]

On Fri 02. Jun - 12:00:37, Kevin Ottens wrote:
> 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!

Ok, that's actually what I wanted. A commitment from both desktops, GNOME
and KDE. So if both sides agree, I can live with it.

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

But that's actually my point. How can lower level layers use it if it is
in session context? Lower level layern usually don't reside in session
context, but nevermind...

[...]

Regards,
	Holger