GNOME Bugzilla – Bug 308233
Add D-Bus interface
Last modified: 2005-09-23 18:56:12 UTC
While a bit buzz-wordy, this would allow for apps to lock and unlock the screen. I can think of a few applications: - locking/unlocking the screen when a bluetooth phone goes in/out of range - special setups where the insertion of a specific device would unlock the screen (a USB key with a special file/password) - locking the screen when the typing break is scheduled (right now, it's not possible to do so when the typing break is on unless you postpone it) The interface would need to be able to: - lock/unlock the screen - unlock the screen if it was locked without user interaction (phone got out of range)
It is actually built on dbus. The gnome-screensaver-command program communicates with the daemon over the session message bus. As of today the interface to lock/unlock is: interface org.gnome.screensaver method setActive (bool enabled) method getActive (void) signal ActiveChanged ()
There's still no way to: - Unlock or lock the screen without disabling/enabling the screensaver - Unlocking the screen with password activation (same behaviour as if you moved the mouse, usually)
You want to be able to blank the screen but not lock it when your bluetooth device is in range? You can set the gconf key /apps/gnome-screensaver/lock to false when the device is in range. The advantage of doing it this way is that the value will be ignored if mandatory settings are in place. I suppose we can make a Dbus interface wrapper for this. Something like: bool setLockEnabled () bool getLockEnabled () signal LockEnabledChanged Is that what you mean?
Disabling the screensaver altogether means that if we stop the bluetooth bits, then the screensaver won't be enabled anymore. What you propose is just a wrapper around GConf, effectively. I'd rather have a: bool setLockScreen (bool active) // returns whether the locking succeeded, probably should have an exception/error returned if not bool getScreenLocked () // Whether the screen is locked bool getScreenLockedTimedout () // Whether the screen was locked because of the timout (ie. it would be False if setLockScreen(True) was called).
Is there any reason then why the screensaver should activate at all when the device is in range? Isn't this really the same as if totem was playing? I prefer to have locking be an internal policy. Ideally apps don't have to know anything about it. The screensaver either locks or it doesn't. The interface to applications is only setActive (bool active). Active means the screen is blanked (and perhaps locked). Is there a PAM method that uses bluetooth devices? I think that would be another way to go.
I think the dbus interface should now handle all of these cases. Bastien, please open a new bug if there is a specific lack. Thanks.