Someone recently contacted me about Tux Paint with this problem:
I’m running Tuxpaint 0.9.15b on Ubuntu 6.06. It is
running in full screen mode. After the kids quit
playing with Tuxpaint (and leave it running) my
screensaver fails to activate. I looked in the
configuration file but see no mention of any settings
there.
Sounds like SDL is disabling screensaver while in fullscreen mode.
Is that by design? Any way around that? Any reason to avoid turning on
the screensaver?
(Maybe I should add a simple screensaver to Tux Paint itself after
an extended amount of inactivity…?)–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/
Hello !> Sounds like SDL is disabling screensaver while in fullscreen mode.
Is that by design? Any way around that? Any reason to avoid turning on
the screensaver?
+++
/* Save DPMS and screensaver settings */
X11_SaveScreenSaver(SDL_Display, &screensaver_timeout, &dpms_enabled);
X11_DisableScreenSaver(SDL_Display);
+++
Yes it is disabled by SDL. Maybe to get sure not loosing context
or so.
(Maybe I should add a simple screensaver to Tux Paint itself after
an extended amount of inactivity…?)
You could make some adverts there for Tux4Kids 
CU
Sounds like SDL is disabling screensaver while in fullscreen mode.
Is that by design? Any way around that? Any reason to avoid turning on
the screensaver?
I suspect it was added for games that never want the screensaver to
enable, so if you’re playing with a joystick, you won’t have to wiggle
the mouse every few minutes to keep the screen from turning off.
TuxPaint is fairly unique among SDL apps in that you could have someone
walk away and not quit…it’s more a regular application and less a game.
(Maybe I should add a simple screensaver to Tux Paint itself after
an extended amount of inactivity…?)
We could probably add an environment variable to SDL for this, but it
might be cleaner to either just ship a hacked SDL that returns
immediately from X11_DisableScreenSaver() or build it into TuxPaint itself.
I could see a value in having the environment variable, since other apps
could use this, too, but on the other hand…another environment
variable?!
Let me know what you think is best.
–ryan.
Hi!
“Ryan C. Gordon” schrieb:
(Maybe I should add a simple screensaver to Tux Paint itself after
an extended amount of inactivity…?)
We could probably add an environment variable to SDL for this, but it
might be cleaner to either just ship a hacked SDL that returns
immediately from X11_DisableScreenSaver() or build it into TuxPaint itself.
I could see a value in having the environment variable, since other apps
could use this, too, but on the other hand…another environment
variable?!
Let me know what you think is best.
What about a “SDL_AllowScreensaver(bool allowit)” ?
Bye,
Tim
What about a “SDL_AllowScreensaver(bool allowit)” ?
Because there’s an unspoken policy: no more API changes in 1.2.
Also, an environment variable says “this isn’t a formal SDL thing, it’s
a hack” and you don’t have to promise it works on every platform.
For SDL 1.3, though…maybe. I feel like I take way too many liberties
in saying what we will and won’t do when it’s really not my call.
–ryan.
> TuxPaint is fairly unique among SDL apps in that you could have someone
> walk away and not quit...it's more a regular application and less a game.
> We could probably add an environment variable to SDL for this, but it
> might be cleaner to either just ship a hacked SDL that returns
> immediately from X11_DisableScreenSaver() or build it into TuxPaint itself.
I believe the machine in question was an Ubuntu box, so it’d be using
the version of libSDL that ships with that distro – not anything I packaged
along with Tux Paint.
> I could see a value in having the environment variable, since other apps
> could use this, too, but on the other hand...another environment
> variable?! :)
>
> Let me know what you think is best.
So, yeah… an env. var. would be spiffy. Thanks! :)On Wed, Mar 14, 2007 at 01:14:53PM -0400, Ryan C. Gordon wrote:
–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/
So, yeah… an env. var. would be spiffy. Thanks!
I’ve put this in Bugzilla, along with a first shot at a patch to SDL:
http://bugzilla.libsdl.org/show_bug.cgi?id=415
Let me know if that covers your needs. I think this can be cleanly
handled on Windows, too, at a minimum.
–ryan.
I’ve put this in Bugzilla, along with a first shot at a patch to SDL:
http://bugzilla.libsdl.org/show_bug.cgi?id=415
Let me know if that covers your needs. I think this can be cleanly
handled on Windows, too, at a minimum.
Bill, will this be acceptable for TuxPaint? I’d like to apply the patch.
–ryan.
I don’t mean to hijack the thread, but what about the opposite case: when
playing a joystick game in a window, the screensaver still comes on, and
mouse wiggling or modifier key pressing must still be employed.
Being a developer I commonly run games windowed because development versions
may crash, and crashing in fullscreen mode with the mouse grabbed is never
fun…
Chris
Just a note, since this thread happened to re-appear today.
Someone emailed me today to let me know that Tux Paint on their iMac
was preventing their system from going to sleep. I’m assuming it’s due
to the fact that SDL is disabling the screensaver, and that, in turn,
makes the Mac think it shouldn’t sleep, either.
Just FYI. Glad it’s been patched. Need to make sure we get the patch and
test it when building Tux Paint binaries, at least.
-bill!On Fri, Apr 06, 2007 at 02:24:36AM -0400, chris guirl wrote:
I don’t mean to hijack the thread, but what about the opposite case: when
playing a joystick game in a window, the screensaver still comes on, and
mouse wiggling or modifier key pressing must still be employed.
I don’t mean to hijack the thread, but what about the opposite case:
when playing a joystick game in a window, the screensaver still comes
on, and mouse wiggling or modifier key pressing must still be employed.
Being a developer I commonly run games windowed because development
versions may crash, and crashing in fullscreen mode with the mouse
grabbed is never fun…
I think that’s what we’re talking about, actually…without this patch,
the Mac OS X and X11 video targets will forcibly disable the
screensaver, windowed or not.
In most cases, that’s desirable behaviour for a game, even in a window,
but for something like TuxPaint that’s actually more of an application
than a game, it’s not.
Also, I haven’t touched the Windows code yet (and would appreciate a
patch from someone else so I don’t have to. ).
In the meantime, I’m committing the existing patch. Bill, grab the
latest branches/SDL-1.2 from Subversion and let me know if it works for you.
–ryan.
Yes I agree that a game should most of the time disable the screensaver both
in windowed and fullscreen modes. However, as far as I can tell my version
of SDL does not do this in windowed mode. If it intends to, it seems
unsuccessful. Whenever play testing VDrift I do it in a 1280x1024 window,
using my gamepad, and without failure my screensaver comes on every
time…It’s somewhat frustrating. I’m using SDL 1.2.10 from the Ubuntu
package, is this something that’s been changed recently? Maybe it’s time I
should check out the latest Subversion code for SDL…On 4/6/07, Ryan C. Gordon wrote:
I think that’s what we’re talking about, actually…without this patch,
the Mac OS X and X11 video targets will forcibly disable the
screensaver, windowed or not.
In most cases, that’s desirable behaviour for a game, even in a window,
but for something like TuxPaint that’s actually more of an application
than a game, it’s not.
every time…It’s somewhat frustrating. I’m using SDL 1.2.10 from the
Ubuntu package, is this something that’s been changed recently? Maybe
it’s time I should check out the latest Subversion code for SDL…
I just committed the change to Subversion this morning, so I guess that
counts as recent.
–ryan.
Oh, I see. Thanks, that’s bugged me for a long time. Checking out the
code now…
ChrisOn 4/7/07, Ryan C. Gordon wrote:
I just committed the change to Subversion this morning, so I guess that
counts as recent.