Rework of the org.freedesktop.ScreenSaver API?
Aaron J. Seigo
aseigo at kde.org
Thu Nov 29 02:16:53 PST 2012
On Wednesday, November 28, 2012 19:10:28 Bastien Nocera wrote:
> I missed the discussions about the old screensaver API that KDE and
> GNOME developers discussed but only KDE implemented:
> ter/entry/ksmserver/screenlocker/dbus/org.freedesktop.ScreenSaver.xml and I
> hope we can work something out now.
> I've implemented a proxy for this in GNOME, which I'll backport to
> 3.6 when it's had a bit of testing. Only the Inhibit/UnInhibit and the
> Throttle/UnThrottle pairs are implemented (and the latter is a no-op).
Would it be possible to have only inhibit/uninhibit, or is throttle actually
useful / used?
> Here's a list of things I think we'd need to clean up in a new API:
> - Only define application API, not system-level API (what's the use
> knowing that the screensaver is actually on, or the session idle time?)
> - What's SimulateUserActivity for? It looks like a way to avoid using
> the API, or maybe a way for apps to not link to D-Bus. I think that we
> should remove this if we agree and implement this API.
It resets the idle time of the system, which various components use to alter
the behaviour of the UI; e.g. if a notification appears while the user is idle,
it waits until there is user activity before starting the countdown to
automatically hide it (giving them a chance to see it once their attention is
back on the system). That said, I'm not sure it makes much sense to expose
this to applications directly.
The reason it is in the DBus API seems to be as a way to expose this
functionality without requiring applications to have support in libraries they
link to. e.g. in KDE's libs we have KIdleTime which implements all this
functionality (and as a result, no KDE apps use this part of the DBus spec).
It may also have been put there as a way to easily port existing applications
that were doing such things "manually" in their code, giving them a 1:1
mapping of functionality rather than requiring they change their code to an
inhibition pattern. If that was the case, I don't agree with it :)
I'd support the position of: "if you want to simulate user activity, then find
an implementation that does so." rather than expose this in the DBus API.
Potential impact of the change: This would only potentially impact 3rd party
applications, user scripts, etc. It's a bit of a stretch imho to justify use
of this API from scripts and the like .. it's really only rather specific (and
usually somewhat special) applications that need to simulate user activity.
Ditto all the above for the idle time API.
So imho the DBUs API could indeed be stripped down a bit into a basic-needs
application API and leave things like idle time to actual libraries.
For KDE's existing support of this API, we'd have to keep the API as-is in any
case to preserve application compatibility .. but we could mark things as
deprecated and remove them in the coming Frameworks 5.0 based releases
> - Inhibition should be done at the session level, with the session
> controlling the screensaver (or the screensaver asking the session,
> whichever). Could we rename the interface to not include "screensaver"
> in the name?
This creates work for those of us who have already implemented it. Other than
the cosmetics of it, what are the benefits of altering the name?
While the name is perhaps not perfect, it would mean that all applications
that currently use this API (probably mostly KDE applications at this point)
would Just Work(tm) without needing any adjustments or alterations. Otherwise
we will need to not only change the application code, but also do some dancing
to ensure those apps work on current/previous releases of KDE's workspaces
(e.g. -> "see if the interface is registered on some new name, if that fails,
try the old name").
So unless there's a really good reason for changing the name, I'd suggest we
leave it, even if it isn't perfect (that being the enemy of good ;)
> - As for the Inhibition APIs, gnome-session can inhibit more than just
> the screensaver (log out, user switching, suspend, and auto-mounting):
We already have /org/freedesktop/PowerManagement/Inhibit for things like
suspension inhibition. It could make sense to try and unify all these
suspension concepts into one DBus API .. though that could also just as easily
be done in library API, preventing churn in the already implemented DBus
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the xdg