Alt-Enter fullscreen toggle

How important is it to people to have Alt-Enter be a built-in hot-key for
users to toggle fullscreen mode? The program has no way of detecting or
preventing this switch. Is it more appropriate for this functionality to
be left up to the application?

If people like this feature, it will probably only be implemented on X11
for some time.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

I think it’s a good thing. First for debugging, it could help in a case
where you otherwise had to kill X, which would bring all other running apps
down too. And it leaves control to the user, where it belongs. I don’t want
to leave it to some random, possibly buggy, game (or whatever) to make sure
I can restore my screen if that can be handled from the more trustworthy
library. It’s like the kill-buttons that the windowmanager puts on apps even
though they have an “exit” menuoption too.

All the best,
robOn Mon, Feb 07, 2000 at 06:37:27PM -0800, Sam Lantinga wrote:

How important is it to people to have Alt-Enter be a built-in hot-key for
users to toggle fullscreen mode? The program has no way of detecting or
preventing this switch. Is it more appropriate for this functionality to
be left up to the application?

on Die, 08 Feb 2000 Robert Linden wrote:>On Mon, Feb 07, 2000 at 06:37:27PM -0800, Sam Lantinga wrote:

How important is it to people to have Alt-Enter be a built-in hot-key for
users to toggle fullscreen mode? The program has no way of detecting or
preventing this switch. Is it more appropriate for this functionality to
be left up to the application?

I think it’s a good thing. First for debugging, it could help in a case
where you otherwise had to kill X, which would bring all other running apps
down too. And it leaves control to the user, where it belongs. I don’t want
to leave it to some random, possibly buggy, game (or whatever) to make sure
I can restore my screen if that can be handled from the more trustworthy
library. It’s like the kill-buttons that the windowmanager puts on apps even
though they have an “exit” menuoption too.

Totally agreed !
Please keep Alt-Enter !


Karsten-O. Laux (@Karsten_Laux)

Sam Lantinga wrote:

How important is it to people to have Alt-Enter be a built-in hot-key for
users to toggle fullscreen mode? The program has no way of detecting or
preventing this switch. Is it more appropriate for this functionality to
be left up to the application?

I like the feature - how about creating an event upon the switch. So at
least the app could notice when it is toggling from fullscreen to
windowed and vice versa.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

I like the feature - how about creating an event upon the switch. So at
least the app could notice when it is toggling from fullscreen to
windowed and vice versa.

Hehe… that way the app. could say “oh no you don’t!” and flip back to
fullscreen. :wink:

-bill!

William Kendrick wrote:

I like the feature - how about creating an event upon the switch. So at
least the app could notice when it is toggling from fullscreen to
windowed and vice versa.

Hehe… that way the app. could say “oh no you don’t!” and flip back to
fullscreen. :wink:

And look frankly horrible as the whole screen flicks back and forth?

Is is that hard for people to listen themselves to the Alt-Enter and
issue a “go fullscreen”/“go windowed”? And as some people mentioned
cases of the app frozen and needing to kill X to get control back, SDL
counts as “the app”, as far as I know and won’t magically run even when
crashed.

I say dump the binding.–
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/

Robert Linden wrote:

I think it’s a good thing. First for debugging, it could help in a case
where you otherwise had to kill X, which would bring all other running apps
down too. And it leaves control to the user, where it belongs. I don’t want
to leave it to some random, possibly buggy, game (or whatever) to make sure
I can restore my screen if that can be handled from the more trustworthy
library. It’s like the kill-buttons that the windowmanager puts on apps even
though they have an “exit” menuoption too.

When the game is frozen, the lib is frozen. The window manager is in
another process completely, so its easy for it to kill off an
application. But SDL can’t do anything more that the app can’t do also.–
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/

When the game is frozen, the lib is frozen.

Sure, if “frozen” == crashed. But it might also be the case that it just is
not accepting/processing any input, in which case key-events might still
work. And I am lazy enough to not want to setup any emergency-escape-events
in every program I’m working on, that’s what libraries are for after all.
Or do you think it hurts in some way if SDL has this feature ?

The window manager is in another process completely, so its easy for it to
kill off an application.

You’re right, that’s something different. But the usage is similar anyway.

But SDL can’t do anything more that the app can’t do also.

But it can do things the app did not want/consider/remember/whatever to do.
It might be handy to switch to windowd mode without killing the SDL-app,
even if it’s author did not care to include this.
(and I do remember that I was in a situation where descent2 did not allow me
to switch consoles (screwed because of some broken screen-modes or bad
handling of this by sdl) but alt-enter worked.)
Or am I missing the point why such emergency-shortcuts are fundamentaly evil ?

All the best,
robOn Tue, Feb 08, 2000 at 06:10:33PM -0500, Pierre Phaneuf wrote:

I fully second this as well - I didn’t count how many reboots I had
in the last years because of broken or hanging svgalib, GGI and
glide programs. (In the meantime I know blindly typing Magic-SysRq
sequences to avoid fscks).

No application should ever have full control over the keyboard.

Markus

---- Markus F.X.J. Oberhumer <@Markus_F.X.J_Oberhum> ----
---- http://wildsau.idv.uni-linz.ac.at/mfx/ ----
---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----

                         3 WARPS TO URANUSOn 08-Feb-2000 Robert Linden wrote:

On Mon, Feb 07, 2000 at 06:37:27PM -0800, Sam Lantinga wrote:

How important is it to people to have Alt-Enter be a built-in hot-key for
users to toggle fullscreen mode? The program has no way of detecting or
preventing this switch. Is it more appropriate for this functionality to
be left up to the application?

I think it’s a good thing. First for debugging, it could help in a case
where you otherwise had to kill X, which would bring all other running apps
down too. And it leaves control to the user, where it belongs. I don’t want
to leave it to some random, possibly buggy, game (or whatever) to make sure
I can restore my screen if that can be handled from the more trustworthy
library. It’s like the kill-buttons that the windowmanager puts on apps even
though they have an “exit” menuoption too.

I fully second this as well - I didn’t count how many reboots I had
in the last years because of broken or hanging svgalib, GGI and
glide programs. (In the meantime I know blindly typing Magic-SysRq
sequences to avoid fscks).

No application should ever have full control over the keyboard.

If the application still grabs the input, then the application will
be windowed… but you’ll still not be able to get out of it.

Some applications need to grab the input to get relative mouse motion.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

my thoughts (MINE!!!, okay im in an odd mood):

my personal opinion is that a program should be able to control switching
from full screen to windowed. the main concern seems to be with the fact
that a program could take over your video and keyboard then freeze and you
wouldnt be able to get out. so maby you should replace it with a binding
that will quit the program, switching out of full screen mode and releasing
input and whatever else it needs to do to return the system to a usable
state first.

Sam Lantinga wrote:> > I fully second this as well - I didn’t count how many reboots I had

in the last years because of broken or hanging svgalib, GGI and
glide programs. (In the meantime I know blindly typing Magic-SysRq
sequences to avoid fscks).

No application should ever have full control over the keyboard.

If the application still grabs the input, then the application will
be windowed… but you’ll still not be able to get out of it.

Some applications need to grab the input to get relative mouse motion.

    -Sam Lantinga                           (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software

“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

The discussion seems to have evolved to be mainly concerned with
built-in hot-keys for ‘escaping’ from the clutches of a buggy app
without having to reach for the reset button and wait for fsck.

In my not so humble but frequently correct opinion, having a fullscreen-
windowed toggle key built in is not desirable unless the programmer can
configure it. If you put the Alt-Enter functionality into SDL, I hope
you allow the programmer to choose whether to enable it or not, or even
possibly to define what keyboard event triggers it.

It is important to realize that this is not a ‘safety feature’ due
to the fact that input may still be grabbed even when the application
is windowed. This is simply a convenience for programmers using
SDL.

Having some keyboard event built in to shutdown SDL cleanly, however
would be highly desirable. Something that transcends the application’s
event handlers and acts even if the application is stuck permanently
off in la-la land. Again, such functionality could be configurable by
the programmer – set what keyboard event you want to use for this
action, or even disable it entirely.

If the application SEGVs or something similarly noxious, I assume
the ‘SDL parachute’ signal handlers of SDL take care of escaping
from a potentially unusable state. …Although I haven’t yet tried
SEGV-ing my applications while they are fullscreen accelerated
via Mesa GLX FX. :slight_smile:

JW

Sam Lantinga wrote:>

How important is it to people to have Alt-Enter be a built-in hot-key for
users to toggle fullscreen mode? The program has no way of detecting or
preventing this switch. Is it more appropriate for this functionality to
be left up to the application?

If people like this feature, it will probably only be implemented on X11
for some time.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software

“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec


// John Watson
// Software Engineer – STScI Archive Team

Sam Lantinga wrote:

How important is it to people to have Alt-Enter be a built-in hot-key for
users to toggle fullscreen mode? The program has no way of detecting or
preventing this switch. Is it more appropriate for this functionality to
be left up to the application?

If people like this feature, it will probably only be implemented on X11
for some time.

Yes, I think that this will be very useful, at least for development
purposes. Most of my debugging is performed on a windowed SDL, for
obvious reasons (beats having to connect a gdb to my running program on
another virtual console, and I no longer have an MDA card that will work
dual-headed), but performance-wise fullscreen is far superior (and so is
better for profiling and algorithmic tweaks). Also useful for the same
reason the magic sysrq key in the new Linux kernels is useful. An
errant fullscreen app could easily freeze X (requiring the use of the
magic sysrq key!), as I found out when first experimenting with SDL
fullscreen.–

| Rafael R. Sevilla @Rafael_R_Sevilla |
| Instrumentation, Robotics, and Control Laboratory |

College of Engineering, University of the Philippines, Diliman

Just to clarify, the hotkey combination only works if the application
is processing events, so if your application is hung, you would not be
able to use a hotkey to escape or restore the video mode.

Also, using SDL 1.1.0, you can choose to enable and disable hotkeys
via the hotkey API (which will probably go away if Alt-Enter is dropped)

The idea is that for applications that are not written to be aware of them,
the hotkeys will provide useful default functionality.

People have raised the concern that the application should be in charge
of handling key sequences explictly, and indeed, the code is very simple*

SDL_Surface screen; / The display screen */

int my_HotKeyFilter(const SDL_Event *event)
{
if ( event->type == SDL_KEYDOWN ) {
if ( (event->key.keysym.sym == SDLK_RETURN) &&
(event->key.keysym.mod & KMOD_ALT) )
Uint32 flags;
int w, h, bpp;

		w = screen->w;
		h = screen->h;
		bpp = screen->format->BitsPerPixel;
		if ( screen->flags & SDL_FULLSCREEN ) {
			flags = screen->flags & ~SDL_FULLSCREEN;
		} else {
			flags = screen->flags | SDL_FULLSCREEN;
		}
		if ( VideoModeOK(w, h, bpp, flags) ) {
			/* This changes the publicly visible surface */
			screen = SDL_SetVideoMode(w, h, bpp, flags);
			if ( screen == NULL ) {
				/* Uh oh... */;
			}
			/* Redraw surface contents ... */
		}
		/* Drop the event */
		return(0);
	}
}
return(1);

}

SDL_SetEventFilter(my_HotKeyFilter);

[*] the code above has not been compiled and tested

See test/testwm.c for more hotkey examples.

The advantage of the current Alt-Enter toggle is that it takes advantage
of internal toggling functionality only available with the X11 driver,
and it does not change the contents of the screen and generally does
not fail.
It does change the screen flags, but otherwise is beyond the application
control. This would be difficult to implement in the other video drivers.

So, that said, who wants to keep the current hotkey functionality?

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Any chance of improving this situation ?

I still want to pause the latest-coolest-Loki-ported game,
press Alt-Enter, minimize it, and forget about it when something
else has to be done. And no application whatsoever should be allowed
to disable this. After all that’s the reason I use Unix.

BTW, am I right that Alt-Enter is processed in the event thread and
is therefore not affected by application bugs such as loops ?

Markus

---- Markus F.X.J. Oberhumer <@Markus_F.X.J_Oberhum> ----
---- http://wildsau.idv.uni-linz.ac.at/mfx/ ----
---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----

                         3 WARPS TO URANUSOn 09-Feb-2000 Sam Lantinga wrote:

I fully second this as well - I didn’t count how many reboots I had
in the last years because of broken or hanging svgalib, GGI and
glide programs. (In the meantime I know blindly typing Magic-SysRq
sequences to avoid fscks).

No application should ever have full control over the keyboard.

If the application still grabs the input, then the application will
be windowed… but you’ll still not be able to get out of it.

Some applications need to grab the input to get relative mouse motion.

I still want to pause the latest-coolest-Loki-ported game,
press Alt-Enter, minimize it, and forget about it when something
else has to be done. And no application whatsoever should be allowed
to disable this. After all that’s the reason I use Unix.

The latest coolest Loki ported games will (almost) always have this
feature. That is of course the reason we port to Linux. :slight_smile:

Type Ctrl-Z in your favorite Loki game. :slight_smile:

This type of functionality will always be doable from the app, the
question is whether to enable shortcuts by default.

BTW, am I right that Alt-Enter is processed in the event thread and
is therefore not affected by application bugs such as loops ?

Only if there is a separate thread for input.
Aborting an application from a separate thread can cause havoc on your
application, possibly locking up your hardware as the threads conflict.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Well, I pretty trust your code but I feel much better if there
is a built-in emergency Alt-Enter that is handled by SDL in a safe
OS type manner (e.g. for my code ;-).

The only benefit in hotkeys I see is that there would be a consistent
default behaviour (key bindings) across most SDL applications.

Markus

---- Markus F.X.J. Oberhumer <@Markus_F.X.J_Oberhum> ----
---- http://wildsau.idv.uni-linz.ac.at/mfx/ ----
---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----

                         3 WARPS TO URANUSOn 09-Feb-2000 Sam Lantinga wrote:

I still want to pause the latest-coolest-Loki-ported game,
press Alt-Enter, minimize it, and forget about it when something
else has to be done. And no application whatsoever should be allowed
to disable this. After all that’s the reason I use Unix.

The latest coolest Loki ported games will (almost) always have this
feature. That is of course the reason we port to Linux. :slight_smile:

No, this in itself is not a good thing. Many applications have their
own unique UI and set of keybindings, and SDL should never alter that
or prevent that.

Hmmm…
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software> On 09-Feb-2000 Sam Lantinga wrote:

I still want to pause the latest-coolest-Loki-ported game,
press Alt-Enter, minimize it, and forget about it when something
else has to be done. And no application whatsoever should be allowed
to disable this. After all that’s the reason I use Unix.

The latest coolest Loki ported games will (almost) always have this
feature. That is of course the reason we port to Linux. :slight_smile:

Well, I pretty trust your code but I feel much better if there
is a built-in emergency Alt-Enter that is handled by SDL in a safe
OS type manner (e.g. for my code ;-).

The only benefit in hotkeys I see is that there would be a consistent
default behaviour (key bindings) across most SDL applications.


“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

I see - then drop the hotkeys, and make Alt-Enter rock solid.

Markus

---- Markus F.X.J. Oberhumer <@Markus_F.X.J_Oberhum> ----
---- http://wildsau.idv.uni-linz.ac.at/mfx/ ----
---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----

                         3 WARPS TO URANUSOn 09-Feb-2000 Sam Lantinga wrote:

I still want to pause the latest-coolest-Loki-ported game,
press Alt-Enter, minimize it, and forget about it when something
else has to be done. And no application whatsoever should be allowed
to disable this. After all that’s the reason I use Unix.

The latest coolest Loki ported games will (almost) always have this
feature. That is of course the reason we port to Linux. :slight_smile:

Well, I pretty trust your code but I feel much better if there
is a built-in emergency Alt-Enter that is handled by SDL in a safe
OS type manner (e.g. for my code ;-).

The only benefit in hotkeys I see is that there would be a consistent
default behaviour (key bindings) across most SDL applications.

No, this in itself is not a good thing. Many applications have their
own unique UI and set of keybindings, and SDL should never alter that
or prevent that.

Hmmm…

Also, I think that SDL, being a low-level library itself, should be as
unintrusive as possible. I tend to think that standard key mappings and
such should be left to higher level libraries to provide consistency. I
guess it just kinda depends on your point of view…

Dave Archbold
Applications Programmer
West Teleservices
Work email: DWArchbold at West.com
Home email: davea at radiks.netOn Wednesday, February 09, 2000 12:16 PM, Sam Lantinga [SMTP:slouken at devolution.com] wrote:

No, this in itself is not a good thing. Many applications have their
own unique UI and set of keybindings, and SDL should never alter that
or prevent that.