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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
