Alt-F4 not working on Windows

SDL Development
41

Time for an API to let the programmer decide! :slight_smile: (and/or env vars)On Thu, May 01, 2008 at 04:07:51PM -0700, Tim Goya wrote:

Darwinia uses ALT-TAB by design to switch between “programs” and other
conventions because the game simulates a fictional OS. SDL should not
restrict that kind of creative freedom.

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

42

cough Star Raiders - Wikipedia

:wink:

-bill!On Fri, May 02, 2008 at 04:26:34AM -0700, Mason Wheeler wrote:

Apples and oranges. The “don’t hook the mouse” rule makes a lot of sense
for windowed programs, and was written in a time before fullscreen gaming
had even been dreamed up.

43

Hello !

Time for an API to let the programmer decide! :slight_smile: (and/or env vars)

Jup. I never thought that a discussion about ALT F4 and
SDL would be so long :slight_smile:

CU

44

Here is, I think, the problem.

On my KDE desktop, ALT+F4 closes windows.
One of my SDL games, which doesn’t listen for ‘Alt’ plus ‘F4’ keystrokes,
quits when I hit ALT+F4. Obviously, it’s reacting to the KDE window manager,
just as though I had clicked the “X” button in the title bar, asked KDE to
log me out, right-clicked the window in my taskbar and selected ‘Close’, etc.

Apparently in Windows, ALT+F4 is NOT handled by the window management
level, and is simply passed along to the application. So SDL doesn’t
specifically listen for this (it doesn’t have to listen for ALT+F4 in KDE,
it just gets a ‘window is being asked to close’ event, just like clicking “X”).

So the question is: do we ADD functionality to SDL to listen for ALT+F4,
on Windows (the oddity here), and pass along SDL_QUIT to the event queue?

If we DO, then we certainly need to make it optional, since many games
and apps may want full-control. (I guess they’re out of luck under
window managers like KWin, unless the user changes their WM shortcuts.)

And in that case, what’s the default behavior? Traditional? (Pass ALT+F4
to the event queue as keypresses.) Or ‘helper’ (send SDL_QUIT)?
To prevent a religious war, I suggest default remains traditional.

And, btw… WOW. What a thread. :slight_smile:

-bill!On Fri, May 02, 2008 at 08:26:49AM -0500, Bob Pendleton wrote:

BTW, having alt-f4 terminate a program (cleanly or not) is not a
fundamental human right. It is a windows convention. A convention that can
be ignored and often is ignored, by developers and users.

45

Here is, I think, the problem.

On my KDE desktop, ALT+F4 closes windows.

And on my KDE destop <>+F4 closes windows, this is why it should be
left to the implementor! too much bother getting this right and nothing is
even broken so why try to fix it?On Fri, 02 May 2008 17:18:17 +0100, Bill Kendrick wrote:

–
Using Opera’s revolutionary e-mail client: Opera Web Browser | Faster, Safer, Smarter | Opera

46

And on my KDE destop <>+F4 closes windows, this is why it should be
left to the implementor! too much bother getting this right and nothing is
even broken so why try to fix it?

Perhaps because we’re talking about the Windows implementation specifically, not about KDE, and because Sam has already acknowledged this as a bug to be fixed.

----- Original Message -----
From: graham.houston@rushpark.co.uk (Graham Houston)
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Friday, May 2, 2008 9:25:51 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
On Fri, 02 May 2008 17:18:17 +0100, Bill Kendrick wrote:

47

And on my KDE destop <>+F4 closes windows, this is why it should
be
left to the implementor! too much bother getting this right and nothing
is
even broken so why try to fix it?

Perhaps because we’re talking about the Windows implementation
specifically, not about KDE, and because Sam has already acknowledged
this as a bug to be fixed.

My reply was to Bill’s message about KDE & ALT+F4 not Windows!On Fri, 02 May 2008 17:28:21 +0100, Mason Wheeler wrote:

----- Original Message ----
From: Graham Houston <@Graham_Houston>
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Friday, May 2, 2008 9:25:51 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
On Fri, 02 May 2008 17:18:17 +0100, Bill Kendrick wrote:

–
Using Opera’s revolutionary e-mail client: Opera Web Browser | Faster, Safer, Smarter | Opera

48

There’s a timely post on roughly this topic on Kotaku.

Summary for people who don’t want to go there: it can take upwards of a
minute and a half, navigating cutscenes, load screens and ponderous menus to
just exit the game. Or, you can alt-f4.

No one should disable default control keys unless they have a good reason,
but it should be possible to do so IMO. Some of the reasons given so far
don’t sound like good reasons to me, but “I’ve already decided to do it this
way, regardless of UI conventions.” If you know your game will be run on a
particular platform, either avoid a scheme that interferes with it, or come
up with unique schemes for each platform it will be run on. Firefox conforms
its menu and control schemes to the platform and I think it works great,
personally.

Also, don’t deprive me of this:

0wnz0rz: "how do I do rocket jump"
Spatula: "press alt-f4"
0wnz0rz: "thanks"
0wnz0rz has left the map

Erik

49

Oh that reminds me of when I was a kid some 20 years ago, and my brother and I were playing some game, and I was doing badly(he was winning), so I told him that it was a special trick to hit CTRL-ALT-DEL. Oh, was he mad!
Good times!----- Original Message -----
From: Erik
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Friday, May 02, 2008 12:06 PM
Subject: Re: [SDL] Alt-F4 not working on Windows

There’s a timely post on roughly this topic on Kotaku.

http://kotaku.com/384339/assassins-creed-i-cant-quit-you

Summary for people who don’t want to go there: it can take upwards of a minute and a half, navigating cutscenes, load screens and ponderous menus to just exit the game. Or, you can alt-f4.

No one should disable default control keys unless they have a good reason, but it should be possible to do so IMO. Some of the reasons given so far don’t sound like good reasons to me, but “I’ve already decided to do it this way, regardless of UI conventions.” If you know your game will be run on a particular platform, either avoid a scheme that interferes with it, or come up with unique schemes for each platform it will be run on. Firefox conforms its menu and control schemes to the platform and I think it works great, personally.

Also, don’t deprive me of this:

0wnz0rz: "how do I do rocket jump"
Spatula: "press alt-f4"
0wnz0rz: "thanks"
0wnz0rz has left the map

Erik

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

50

hello,

alt-f4 for games under windows - especially full screen games, often
do NOT close the program.

That’s the convention for windows games that I’ve noticed for ages.
Some games quit this way, but a lot don’t.

Games get you out of the windows, and take over the computer. You
don’t have the same look, or feel with windows games - no conventions
should apply :slight_smile:

Generally - I think anything that allows your game to work x-platform
is good for SDL. However following OS conventions is nice - but I
don’t think alt+f4 for games is a windows convention.

  • cu
51

alt-f4 for games under windows - especially full screen games, often
do NOT close the program.

Games get you out of the windows, and take over the computer. You
don’t have the same look, or feel with windows games - no conventions
should apply :slight_smile:

How about for a program that is in windowed mode rather than fullscreen?On Fri, May 2, 2008 at 4:37 PM, Ren? Dudfield wrote:

–

52

alt-f4 for games under windows - especially full screen games, often
do NOT close the program.

Games get you out of the windows, and take over the computer. You
don’t have the same look, or feel with windows games - no conventions
should apply :slight_smile:

How about for a program that is in windowed mode rather than fullscreen?

That would be a suitable situation, however I just don’t see that any of
this has anything to do with a problem in SDL rather the game/app
developer not applying the appropriate behaviour. SDL does not exit when
you click the icon either, you have to trap it and write the quit
routine yourself… just like the ALT-F4 key combo!!!

Graham.On Sat, 03 May 2008 01:11:24 +0100, Pierre Phaneuf wrote:

On Fri, May 2, 2008 at 4:37 PM, Ren? Dudfield wrote:

–
Using Opera’s revolutionary e-mail client: Opera Web Browser | Faster, Safer, Smarter | Opera

53

Ren? Dudfield wrote:

Games get you out of the windows, and take over the computer. You
don’t have the same look, or feel with windows games - no conventions
should apply :slight_smile:

It is precisely for full-screen games that alt-f4 is most important.
With a windowed game, you can just click on the little x in the
top-right corner of the window. When a full-screen game is misbehaving,
the user needs some way to regain control. By convention, there are
four ways:
alt-f4: quit
alt-enter: switch to windowed mode
alt-tab: switch to another program
ctrl-alt-del: task manager

There are some exceptional situations (e.g. emulators) where the
standard conventions do not apply. SDL /should/ support these
exceptional situations. However, a normal full-screen game has no
excuse for ignoring the standard conventions.–
Rainer Deyke - rainerd at eldwood.com

54

alt-f4 for games under windows - especially full screen games, often
do NOT close the program.

Games get you out of the windows, and take over the computer. You
don’t have the same look, or feel with windows games - no
conventions
should apply :slight_smile:

How about for a program that is in windowed mode rather than
fullscreen?

That would be a suitable situation, however I just don’t see that
any of
this has anything to do with a problem in SDL rather the game/app
developer not applying the appropriate behaviour. SDL does not exit
when
you click the icon either, you have to trap it and write the quit
routine yourself… just like the ALT-F4 key combo!!!

Of COURSE SDL doesn’t exit when you click the X button! The program
itself needs to clean up its memory and close when that happens!
FORCING the SDL program to quit would just be stupid because what if
you have open files, or data that needs saving? SDL has NO idea what
the designer needs to do before quitting the program. Maybe the
designer wants to ask the user if he’s sure he wants to quit, and just
forcing the game to shutdown would DESTROY that sort of thing.

Thus my argument that there’s rather very little point in forcing Alt-
F4 to generate an SDL_QUIT event. You still have to capture the event
and handle it yourself, and this limits your ability to make sensical
control schemes. Yes, yes, it wouldn’t be THAT hard to come up with a
different control scheme under Windows than Linux/Mac, but I like the
idea that one game will be the same under all platforms. Games aren’t
web browsers. They have different UIs, different cursors, and there’s
never been any need for a game to look like it belongs on a given
platform versus any other given platform. So why, then, must every
game adhere to the standards set forth by Microsoft years ago? A
standard which, by the way, many games DO choose to ignore.

Thus, I feel it is not a bug in SDL to not generate an SDL_QUIT event
when Alt-F4 is pressed. I have no objection to making a new event,
something which addresses this specific way of closing a program.

However, in the interest of completeness, is Alt-F4 supposed to quit
the WHOLE PROGRAM, or just close the top window?

Incidentally, there is no equivalent to this “feature” under Mac OS
for closing programs; and on a “me as a user” level, I’ve always felt
Alt-F4 to be a rather dated, obscure relic which, once moved into the
world of modern OS and UI design is too archaic to bother with.

my_two_cents++;

– Scott

55

Sigh, was busy for a few days and took a while to catch up on the
thread, heh! It’s been nice to see a variety of views.

First off, if ya don’t process the SDL_QUIT event, then clicking on
the close action doesn’t kill the program, only a nice hard 'kill -9’
appropriate to whatever OS you’re running will do the trick (task
manager, etc). SDL receives the shutdown request and passes said
request to the app as an SDL_QUIT. It’s up to the application to
quit.

Secondly, ALT-F4 is a windows convention. SDL is multiplatform. If
the OS/WM doesn’t send a QUIT command to the application on a given
keypress, why should SDL assume the user’s intention ? You’re
typically never directly in contact with the hardware and there’s
always some form of abstraction these days, if a convention was to be
enforced, I’d imagine it’d be done there (below SDL). If your game
desires to run under Windows, then adding your own quick check for
ALT-F4 is quick an easy, which can then call an SDL_PushEvent() for
SDL_QUIT (or however you wish to reduce duplicate code in your app).

Second-point-fively, if we’re going to follow OS convention, then
should SDL also implement CTRL-C and CTRL-V under Windows for
clipboard controls ? Those are much more common key presses, and much
more likely to be used in a game. Most OS/WM stuff offer clipboards,
too. Lets not forget copying an IP address and pasting it into an FPS
/connect console command :). Is clipboard control less system level
than a windows close ? How about drag and drop ? I remember when these
things became major additions to xfree window managers. And lets not
forget the mention of ALT-TAB via Darwinia.

Third, Sam suggested a post on bugtraq. This doesn’t necessarily mean
he’s condoned it as a full blown bug that needs to be fixed… it more
or less means it should be looked at, discussed, and decided upon. A
metaphor could be drawn with prosecution, where the police may arrest
someone but not necessarily post charges. Arresting them is just part
of procedure with the full course of action yet to be determined.

Fourth, standards compliant fun. Fun because both sides of the fence
are right :). In the case of games, media players, etc where the
keyboard isn’t used as a typical text entry device, a give key layout
might lend itself more comfortably to a set of input controls. I do
know that, when writing my in-house multiplatform apps, I prefer the
keyboard layout of the tool to be the same across each supported
platform, rather than having to hopscotch around several OS/WM
conventions. I’ll also admit that there are times when not having the
suggested action occur from a given input event doesn’t yield the
suggested outcome, I’m thrown back the first couple times until I
learn how to do what’s needed. Is it MY RIGHT as a user to have
things perform the same way across all applications of my given OS ?
Or is it MY RIGHT as a user to have the application perform the same
across any OS ? Or, as a developer, is it MY RIGHT to have the
application perform as I see is best ? Or is this even a rights issue
at all ? I, personally, don’t see it as a rights issue. It’s a
design choice.

File, Edit, Help have been Windows menuing mainstays for over a
decade, and they’re proposed/suggested menuing guidelines. In games
they don’t make much sense. Long ago, I remember reading a (possibly
Dovorak) article saying how it doesn’t fit alot of regular commercial
apps as well.

As mentioned in an earlier thread by myself and also mentioned by
other ppl, an SDL_foo library to handle this is probably the best
approach… or an entire underbelly of the event handler (not
necessarily just keyboard level, there could be a time where some
other input device is relavent) that also keeps an eye out for
relevant OS/WM input-events that should be reacted upon. Then the fun
argument of if you keep backwards code compatibility with the 'old’
way of doing things and offer an _Init(), environment, etc … or…
if you force the new way upon the developers, requiring them to
disable it if they see fit (and possibly patch their existing projects
if they want to) ?

Just to reiterate, a design choice - not something to be forced down
our throats - in my opinion :).

-Will

PS: “Incidentally, there is no equivalent to this “feature” under Mac
OS for closing programs; and on a “me as a user” level, I’ve always
felt Alt-F4 to be a rather dated, obscure relic which, once moved into
the world of modern OS and UI design is too archaic to bother with.”
— I’ve always wondered why we can reboot any home PC/Mac with a
keyboard combination when we can’t verify who’s at the keyboard. Yes,
that’s a security question in ‘when do you give up all trust’, but…
still seems dangerous and sloppy to me :slight_smile: (even from a non-security
stand point).

56

Will Langford wrote:

Secondly, ALT-F4 is a windows convention. SDL is multiplatform. If
the OS/WM doesn’t send a QUIT command to the application on a given
keypress, why should SDL assume the user’s intention ?

Normally Windows /does/ send a window close command on alt-f4. The
issue is that SDL isn’t properly passing on the keyboard input to allow
Windows to handle it.

In my own programs, I just treat command-q and alt-f4 as quit commands,
regardless of WM and OS. This solves the problem, but might surprise
users of operating systems that use another key combination.–
Rainer Deyke - rainerd at eldwood.com

57

What part of the SDL does actually prevent the WM_DESTROY event that every other windows program gets when I hit ALT-F4?–
Christoph
from Hamburg, Germany

58

What part of the SDL does actually prevent the WM_DESTROY event that
every other windows program gets when I hit ALT-F4?

none, you just have to catch the ALT-F4 key combo and do what you must…

if ALT-F4 caused the SDL_QUIT event then how do you tell the difference
between a SDL_QUIT that was caused by the icon and the key combo? it
just gets very obscure and silly… nothing here is broken, if you want
ALT-F4 to close the app/game then just catch the key combo and do what you
do for SDL_QUIT event… simple!

Graham.On Sat, 03 May 2008 16:49:27 +0100, Christoph Kobe wrote:

–
Using Opera’s revolutionary e-mail client: Opera Web Browser | Faster, Safer, Smarter | Opera

59

What part of the SDL does actually prevent the WM_DESTROY event that
every other windows program gets when I hit ALT-F4?

none, you just have to catch the ALT-F4 key combo and do what you must…

This is not true since every other windows program will get a WM_DESTROY event if you hit ALT-F4 or if you press the icon. If you were right every other windows program would have to catch keyboard events and look for ALT_F4, but this is done (AFAIK) by the window manager and not by the application.

if ALT-F4 caused the SDL_QUIT event then how do you tell the difference
between a SDL_QUIT that was caused by the icon and the key combo?

This is true, you would not be able to tell the difference from the view of the SDL app. But why should one care how the Program closes? I think you can’t tell either if your program was terminated by clicking or by using the task manager to terminate the process. But that’s the point, there are several ways to terminate a Program (ALT-F4, , Taskmanager, etc.) but all a windows program gets is the WM_DESTROY message.

it
just gets very obscure and silly… nothing here is broken, if you want
ALT-F4 to close the app/game then just catch the key combo and do what you
do for SDL_QUIT event… simple!

It’s not that simple because on other systems I don’t want ALT_F4 to terminate the program but to use that systems key combination, which can be different from ALT-F4.On Sat, 03 May 2008 16:59:30 +0100 “Graham Houston” <graham.houston at rushpark.co.uk> wrote:

On Sat, 03 May 2008 16:49:27 +0100, Christoph Kobe <@Christoph_Kobe> wrote:

Graham.

–
Using Opera’s revolutionary e-mail client: Opera Web Browser | Faster, Safer, Smarter | Opera

–
Christoph
from Hamburg, Germany

60

What part of the SDL does actually prevent the WM_DESTROY event that
every other windows program gets when I hit ALT-F4?

none, you just have to catch the ALT-F4 key combo and do what you
must…

This is not true since every other windows program will get a WM_DESTROY
event if you hit ALT-F4 or if you press the icon. If you were right
every other windows program would have to catch keyboard events and look
for ALT_F4, but this is done (AFAIK) by the window manager and not by
the application.

if ALT-F4 caused the SDL_QUIT event then how do you tell the difference
between a SDL_QUIT that was caused by the icon and the key combo?

This is true, you would not be able to tell the difference from the view
of the SDL app. But why should one care how the Program closes? I think
you can’t tell either if your program was terminated by clicking or
by using the task manager to terminate the process. But that’s the
point, there are several ways to terminate a Program (ALT-F4, ,
Taskmanager, etc.) but all a windows program gets is the WM_DESTROY
message.

it
just gets very obscure and silly… nothing here is broken, if you want
ALT-F4 to close the app/game then just catch the key combo and do what
you
do for SDL_QUIT event… simple!

It’s not that simple because on other systems I don’t want ALT_F4 to
terminate the program but to use that systems key combination, which can
be different from ALT-F4.

And if I want ALT-F4 on Windows to not close the window but do something
else ?? im buggered!!

if this was to be implemented in SDL then you can bet your ass than many
programs that already exist and use ALT-F4 for other reasons will not work
as expected… instead of doing what was intended of the combo it quits the
program!!! this would be a bug!!

and on other systems its the same story regardless you mixing up user
interface ethics with bugs here! if you want ALT-F4 to call WM_DESTROY
catch the combo and pump the SDL_QUIT event.

Graham.

– Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/On Sat, 03 May 2008 17:23:53 +0100, Christoph Kobe wrote:

On Sat, 03 May 2008 16:59:30 +0100 “Graham Houston” <@Graham_Houston> wrote:

On Sat, 03 May 2008 16:49:27 +0100, Christoph Kobe wrote: