Opened 15 years ago
Last modified 12 years ago
#33 accepted enhancement
use dbus get notifications of screensaver state changes — at Version 4
| Reported by: | Antoine Martin | Owned by: | Antoine Martin |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.12 |
| Component: | Client | Keywords: | |
| Cc: |
Description (last modified by )
On linux we use xlib to know the "idle time" of the X session and compare that against the timeout value.
We could just do something more similar to what we do on win32 and get notifications when the screensaver is (de)activated:
dbus-monitor --session "type='signal',interface='org.gnome.ScreenSaver',member='SessionIdleChanged'"
More information about the dbus interface, and in particular the ActiveChanged signal in the gnome-screensaver doc
The FAQ contains an example of actions using dbus-monitor: perform_actions_when_the_screensaver...
For reference, the win32 code is track-session-events (from the great win32_how_do_i)
Synergy+ has a bug entry with useful links in it: Support for gnome-screensaver as well as xscreensaver
Some other useful pointers:
- gnome screensaver discussion on mailing list, dated 2006. Refers to
org.gnome.ScreenSaver - idle.c module for X11 used by gajim, which calls
XScreenSaverQueryInfo. - idle.c module for OSX (uses IOKIT via C)
Change History (4)
comment:1 Changed 15 years ago by
| Summary: | use dbus to learn about screensaver state changes → use dbus get notifications of screensaver state changes |
|---|
comment:2 Changed 15 years ago by
| Owner: | changed from Antoine Martin to Antoine Martin |
|---|---|
| Status: | new → accepted |
comment:3 Changed 15 years ago by
Found code that does exactly that (both as a process and with direct dbus calls): http://nxsy.org/getting-amarok-to-pause-when-the-screen-locks-using-python-of-course
comment:4 Changed 14 years ago by
| Description: | modified (diff) |
|---|
copyleft 2009 - 2014
Seeing the painful bugs we had with avahi/dbus python integrating with twisted (removed them in r1626), it might be difficult to integrate this asynchronous dbus stuff with twisted... not sure. If it is, maybe we could just launch a separate process to shield us from this (and monitor/parse its output): very ugly solution but also much safer!