screensaver and power manager dbus interfaces
hmacht at suse.de
Fri Jun 2 13:14:14 EEST 2006
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
> > 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...
More information about the xdg