Problems with Screensavers and other activity sensitive demons.

[Carsten Haitzler (The Rasterman)]

On Thu, 07 Jun 2007 02:02:01 +1000 Graeme Gill <graeme2 at argyllcms.com> babbled:

XScreenSaverSuspend(). it's there. it's engineered. it's documented. the
problem lies  not in lack of engineering in the X11 department. its a very
clean implementation and exactly what you need. if screensaver apps are hacking
around the xscreensaver extension and not using XScreenSaverSelectInput() +
XScreenSaverNotifyEvent's - then they need to be corrected ad they simply are
not playing nice (tm).

> [William Jon McCann suggested I post a summary of these issues here]
> 
> I'm the author of an X11 application for calibrating
> and profiling displays. Like some other applications
> (ie. slideshow presentations, movie playback) my application
> is one in which the user starts, and then doesn't touch
> the system while it's running. It may then take some
> minutes to an hour or so to complete. Because there is no
> keyboard or mouse input, traditional activity cues are missing.
> Having a screensaver or power monitor trigger while in the process
> of presenting test patches to the screen so that they can
> be measured automatically by a spectrometer is a bad thing,
> and may then waste a lot of user time.
> 
> To avoid this I went to the trouble in my application
> of temporarily disabling the screensaver while it is running,
> using the documented mechanism under X11 for doing this:
> XSetScreenSaver(). It didn't take long to discover that
> this in fact was ineffective on the Red Had clone system
> I was testing on. Some investigation revealed that
> the screensaver favoured by that distribution (xscreensaver)
> wasn't playing nice with X11, and in fact was ignoring
> the X11 screensaver mechanism. Perusal of the authors
> website indicated that he had no interest in fixing this
> problem, but merely suggested that application such
> as mine run the "xscreensaver-command -deactivate"
> periodically. Since there seem no other easy to implement
> way of disabling xscreensaver, added a fork() then execlp()
> every 60 seconds to do this. Ugly but it worked.
> 
> Recently I have had a report from a user indicating that
> a screensaver had interrupted calibration of his display.
> Enquiry revealed that it was a new screensaver, the
> GnomeScreensaver. Perusal of it's web site indicated
> that once again, it is not backwards compatible with
> the X11 screensaver mechanism, and that it uses yet another
> method of control, this time based on D-Bus. While this seems a
> little better choice than the xscreensaver approach, the lack
> of backwards compatibility is distressing, and the means of
> signalling activity so that it doesn't trigger bodes poorly
> for future compatibility. It apparently needs a
> "dbus-send --dest=org.gnome.ScreenSaver /org/gnome/ScreenSaver
> org.gnome.ScreenSaver.SimulateUserActivity" every so often (why does
> "org.gnome.Screensaver have to be repeated 3 times in the dbus-send syntax ?
> Surely once is enough!)
> 
> This looks bad, as it seems certain that when someone develops
> a KDE screensaver, org.kde.screensaver will need signalling,
> and when fred develops a new screensaver, com.fred.screensaver will
> need signalling etc. And what about power monitoring demons ? Will
> they each need to be named and known, and a long list added to
> as people add new ones to the operating systems, each time triggering
> a flood of support calls for applications such as mine ?
> 
> There doesn't seem like there's much system level design going
> on here, just each application having to look after itself.
> 
> It would be good if D-Bus is to be the channel for it,
> that there was one central entity that has to be signalled
> to indicate activity, rather than signalling each application
> interested in activity individually.
> It would also be good if the screensavers could hook into
> the existing X11 screensaver mechanism, so that existing
> applications don't break either.
> 
> My application is cross-platform, and solving the screensaver
> problems on MSWindows and OS X was not anywhere as complicated
> (SetThreadExecutionState(ES_DISPLAY_REQUIRED),
> and UpdateSystemActivity(OverallAct) respectively.)
> 
> Hopefully this feedback may trigger some proposals to solve
> these sorts of problems in a more elegant way than at present.
> 
> Graeme Gill.
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)