On Fri, 16 Nov 2001, Andriy Palamarchuk wrote:
--- Andreas Mohr andi@rhlx01.fht-esslingen.de wrote:
On Wed, Nov 14, 2001 at 07:22:39AM -0800, Andriy Palamarchuk wrote:
Change log:
SystemParametersInfo. Implemented processing for actions SPI_GET/SETSCREENSAVETIMEOUT, SPI_GET/SETSCREENSAVEACTIVE, SPI_GET/SETSCREENSAVERRUNNING. Removed integration with X Window screen saving.
Hmm, why did you remove X11 screen saving completely ??
[...]
Andreas, I had a discussion with Alexandre how we are going to integrate system parameters/system metrics with X settings. The decision we came to was to make system parameters independent from X settings by default. This is why I removed the code, not just fixed it. Look at the discussion in a couple of threads on wine-devel with "SystemParametersInfo ..." in subject. The summary of the approach is also in comments to SystemParametersInfoA in windows/sysparams.c
I guess I should do it...
I assumed that in this case there was no strong reason for such integration.
I don't know for SETSCREENSAVETIMEOUT but an application would want to get SETSCREENSAVEACTIVE and SPI_GETSCREENSAVERRUNNING right.
SPI_GET/SETSCREENSAVEACTIVE seems to be typically used by movie players. Imagine, you start palying a DVD, relax, and every five minutes the screensaver kicks in. This is why many movie players disable the screensaver when you start playing the movie and restore its initial state when the movie is finished. This is the case of mplayer for instance (and yes, it's a pain if they crash). I don't see why we should prevent Windows applications from doing so. Similarly, SPI_GETSCREENSAVERRUNNING could be used by an application to stop its slide-show since noone will be able to see it. But actually, it now occurs to me that it may also be used by distributed-computing applications to know when to start their computations (for those that are not screen-savers). SPI_SETSCREENSAVERRUNNING seems pure evil though (and according to the doc applications are not supposed to use it anyway).
In fact, I disagree with Alexandre when he says:
If users want to reconfigure X behavior, they have to use the X configuration programs.
I think Wine is about more than just running Windows applications on Linux. It's about integrating Windows and Linux applications and thus they should be able to manipulate these kind of settings. Otherwise Wine would only support the 'desktop mode' or it would not exist at all and everyone would be happy with running Windows in a sand-box ala VMWare.
So it may make sense to maintain some parameters separately from the X settings (especially when their is not corresponding X setting), but I think the above parameters should be 100% backed by the corresponding X setting.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux