On Thu, 07 Jun 2007 02:02:01 +1000 Graeme Gill <[EMAIL PROTECTED]> 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg