Rework of the org.freedesktop.ScreenSaver API?

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:
> https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/mas
> ter/entry/ksmserver/screenlocker/dbus/org.freedesktop.ScreenSaver.xml and I
> hope we can work something out now.

cool ...

> I've implemented a proxy for this in GNOME[2], 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):
> http://git.gnome.org/browse/gnome-session/tree/gnome-session/org.gnome.Sessi
> onManager.xml#n148

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 
services underneath.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20121129/e4e5b946/attachment.pgp>