Rework of the org.freedesktop.ScreenSaver API?

[Bastien Nocera]

On Thu, 2012-11-29 at 11:16 +0100, Aaron J. Seigo wrote:
> 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?

GNOME has not use for throttle, we don't have screensaver animations. I
thought it might be used in KDE apps, so I implemented no-ops for it.

No objections getting it removed for me.

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

I think idle time can be better monitored directly from X. You have
KIdleTime, we have GnomeIdleMonitor in gnome-desktop.

This should only really be used for system level integration (the
notification daemon, the shell, whatever ends up presenting the
notification), so I don't see a point having it in a D-Bus spec.

And if it's really needed for apps, we can always re-add it later.

> 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

We can bump the version/change the name of the API entry point. Then you
could support both versions of the "spec".

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

The good reason is that KDE's been using that name with this particular
API, with the expectation from application developers that such and such
function are working and will remain working.

Removing functions from the D-Bus API as you've implemented without
renaming it is akin to removing functions in a shared library without
bumping the soname.

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

We, as in, KDE? I don't see this being available anywhere on my system.

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

I don't think that application developers should have to look in two
separate places for inhibition APIs. Having the API split like that
based on implementation details is just bad.

And I don't see what log out, user switching or auto-mount inhibition
would have to do in PowerManagement.

Cheers