Discussion:
Alt-F4 not working on Windows
(too old to reply)
Christoph Kobe
2008-04-30 18:23:11 UTC
Permalink
Hi,
I've been using the SDL for one week now and I'm quite happy with it.

But there's one thing I noticed: When I press Alt-F4 to close the App it won't.
I'm catching the SDL_QUIT event, but it only occurs when I press the X to close the window, Alt-F4 won't do the job.

In the release notes it says that from version 1.2.10 this problem is fixed, I use the SDL-devel-1.2.13-VC6.zip package.

Any Ideas?
Abhinav Lele
2008-04-30 22:07:10 UTC
Permalink
You need to check your code. Alt + F4 works on windows. You have to
check for the event of Alt + F4 and then quit.

SDL_Event event;
int flag;
flag = SDL_PollEvent(&event);
if(flag) { // flag == 1 implies event to be checked for
switch(event.type) {
case SDL_QUIT:
return false; // no need for break;
case SDL_KEYUP:
case SDL_KEYDOWN:
cout << "Key !\n";
if(event.key.keysym.sym == SDLK_F4 && (event.key.keysym.mod ==
KMOD_LALT || event.key.keysym.mod == KMOD_RALT) ) return false;
//return true;
break;
default:
break;
}

This is a code snippet of how I catch alt + f4 in one of my apps. the
snippet returns whether to keep running or not.
Post by Christoph Kobe
Hi,
I've been using the SDL for one week now and I'm quite happy with it.
But there's one thing I noticed: When I press Alt-F4 to close the App it won't.
I'm catching the SDL_QUIT event, but it only occurs when I press the X to close the window, Alt-F4 won't do the job.
In the release notes it says that from version 1.2.10 this problem is fixed, I use the SDL-devel-1.2.13-VC6.zip package.
Any Ideas?
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Mason Wheeler
2008-04-30 22:49:43 UTC
Permalink
If that's what has to be done, then IMO it hasn't been fixed. <ALT>-<F4> is a Windows standard. It always means "quit" on every program. (A few games I've seen override this behavior, which I consider very poor design.) Since by default, <ALT>-<F4> means "quit", it should always generate a SDL_QUIT event, not a SDL_KEYDOWN event. (Same goes for <Command>-Q on Macs.)

----- Original Message ----
From: Abhinav Lele <***@gmail.com>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Wednesday, April 30, 2008 3:07:10 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Abhinav Lele
You need to check your code. Alt + F4 works on windows. You have to
check for the event of Alt + F4 and then quit.
Sean D'Epagnier
2008-04-30 22:58:23 UTC
Permalink
I disagree. Why don't you just exit your application if want ALT-F4 to quit?
Post by Mason Wheeler
If that's what has to be done, then IMO it hasn't been fixed. <ALT>-<F4> is a Windows standard. It always means "quit" on every program. (A few games I've seen override this behavior, which I consider very poor design.) Since by default, <ALT>-<F4> means "quit", it should always generate a SDL_QUIT event, not a SDL_KEYDOWN event. (Same goes for <Command>-Q on Macs.)
----- Original Message ----
Sent: Wednesday, April 30, 2008 3:07:10 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Abhinav Lele
You need to check your code. Alt + F4 works on windows. You have to
check for the event of Alt + F4 and then quit.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Abhinav Lele
2008-04-30 23:21:55 UTC
Permalink
Mason,

Why do you presume Alt+F4 to be a quit trigger. Here is an example.
Blender. Famous 3D design application. Although blender traps alt+f4,
but if you look the shortcut given for exit in its menu, it shows Ctrl
+ Q.
SDL has to be generic you cannot always assume that Alt+F4 is quit.
Post by Mason Wheeler
If that's what has to be done, then IMO it hasn't been fixed. <ALT>-<F4> is a Windows standard. It always means "quit" on every program. (A few games I've seen override this behavior, which I consider very poor design.) Since by default, <ALT>-<F4> means "quit", it should always generate a SDL_QUIT event, not a SDL_KEYDOWN event. (Same goes for <Command>-Q on Macs.)
Jacob Welsh
2008-04-30 23:36:37 UTC
Permalink
That's the point. Alt-F4 is part of the operating system's interface;
that should not concern the programmer any more than "minimize" or
Alt-Tab. If you check for Alt-F4 events yourself, you're making the
unreasonable assumption that all operating systems supported by SDL have
this convention, which is not the case. On Linux it is perfectly
reasonable for the user to remap Alt-F4 to something else, and have some
other shortcut for "close".

On Linux, the Close button, Alt-F4, Ctrl+C, SIGTERM etc. all generate an
SDL_QUIT event; I assume this is also the intended behavior on Windows,
and it ought to be if it's not.
Post by Abhinav Lele
Mason,
Why do you presume Alt+F4 to be a quit trigger. Here is an example.
Blender. Famous 3D design application. Although blender traps alt+f4,
but if you look the shortcut given for exit in its menu, it shows Ctrl
+ Q.
SDL has to be generic you cannot always assume that Alt+F4 is quit.
Post by Mason Wheeler
If that's what has to be done, then IMO it hasn't been fixed. <ALT>-<F4> is a Windows standard. It always means "quit" on every program. (A few games I've seen override this behavior, which I consider very poor design.) Since by default, <ALT>-<F4> means "quit", it should always generate a SDL_QUIT event, not a SDL_KEYDOWN event. (Same goes for <Command>-Q on Macs.)
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Jacob Welsh
TJHSST, Class of 2008
***@gmail.com | http://www.tjhsst.edu/~jwelsh/
Jonathan Dearborn
2008-05-01 01:57:41 UTC
Permalink
That's what I was gonna say: If you specifically code to catch the conventional alt-F4, then your program will not follow the conventions on other systems (i.e. no longer multi-OS-friendly). But if alt-F4 does generate an SDL_QUIT event, I think it would be tougher to work around than having to use preprocessor directives in the other case. Despite this, my personal preference would be to send SDL_QUIT... Someone should make the call on this, but until then, preprocessor is the way to go. Just add an #ifdef __WIN32__ or something.

Jonny D



Date: Wed, 30 Apr 2008 19:36:37 -0400
From: ***@gmail.com
To: ***@lists.libsdl.org
Subject: Re: [SDL] Alt-F4 not working on Windows









That's the point. Alt-F4 is part of the operating system's interface;
that should not concern the programmer any more than "minimize" or
Alt-Tab. If you check for Alt-F4 events yourself, you're making the
unreasonable assumption that all operating systems supported by SDL
have this convention, which is not the case. On Linux it is perfectly
reasonable for the user to remap Alt-F4 to something else, and have
some other shortcut for "close".



On Linux, the Close button, Alt-F4, Ctrl+C, SIGTERM etc. all generate
an SDL_QUIT event; I assume this is also the intended behavior on
Windows, and it ought to be if it's not.



Abhinav Lele wrote:

Mason,

Why do you presume Alt+F4 to be a quit trigger. Here is an example.
Blender. Famous 3D design application. Although blender traps alt+f4,
but if you look the shortcut given for exit in its menu, it shows Ctrl
+ Q.
SDL has to be generic you cannot always assume that Alt+F4 is quit.



If that's what has to be done, then IMO it hasn't been fixed. <ALT>-<F4> is a Windows standard. It always means "quit" on every program. (A few games I've seen override this behavior, which I consider very poor design.) Since by default, <ALT>-<F4> means "quit", it should always generate a SDL_QUIT event, not a SDL_KEYDOWN event. (Same goes for <Command>-Q on Macs.)


_______________________________________________
SDL mailing list
***@lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Jacob Welsh
TJHSST, Class of 2008
***@gmail.com | http://www.tjhsst.edu/~jwelsh/




_________________________________________________________________
Express yourself wherever you are. Mobilize!
http://www.gowindowslive.com/Mobile/Landing/Messenger/Default.aspx?Locale=en-US?ocid=TAG_APRIL
Justin Coleman
2008-04-30 23:34:42 UTC
Permalink
Post by Mason Wheeler
<ALT>-<F4> is a Windows standard.
SDL runs on more than just windows.

-Justin
Jeff
2008-05-01 03:10:16 UTC
Permalink
<ALT>-<F4> is a Windows standard.
Which means it's not a standard. If it should be a standard *for Windows*,
then it's up to *Windows* to handle it by gracefully terminating the program.
If that's the way you want it to work, complain to Bill Gates.

Jeff
a***@cox.net
2008-05-01 03:13:04 UTC
Permalink
Thats pretty short sighted Jeff, I'm an OSS proponent as well, but come on :P
Post by Jeff
<ALT>-<F4> is a Windows standard.
Which means it's not a standard. If it should be a standard *for Windows*,
then it's up to *Windows* to handle it by gracefully terminating the program.
If that's the way you want it to work, complain to Bill Gates.
Jeff
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Charles McGarvey
2008-05-01 03:36:52 UTC
Permalink
Except it's not up to the OS to terminate programs; programs generally
terminate themselves, and in this case SDL is providing the means. Your
comment probably doesn't progress the discussion very well. The question
is, should SDL adhere to the standards of the operating system which is
supports or not. To weigh in, I think it's a good idea in this case.

chaz

----- Original Message -----
From: "Jeff" <***@pacbell.net>
To: "A list for developers using the SDL library. (includes SDL-announce)"
<***@lists.libsdl.org>
Sent: Wednesday, April 30, 2008 9:10 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Jeff
<ALT>-<F4> is a Windows standard.
Which means it's not a standard. If it should be a standard *for Windows*,
then it's up to *Windows* to handle it by gracefully terminating the program.
If that's the way you want it to work, complain to Bill Gates.
Jeff
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Jeff
2008-05-01 06:14:49 UTC
Permalink
Post by Charles McGarvey
Except it's not up to the OS to terminate programs;
If a particular key combination is alleged to be a universal quit for any
program, then it is up to the OS to terminate the program. It's the
equivalent of the Unix 'kill -9' command. Or have I not understood Mason's
complaint?
Post by Charles McGarvey
The question
is, should SDL adhere to the standards of the operating system which is
supports or not. To weigh in, I think it's a good idea in this case.
I agree. A good idea, however, is not the same as a requirement. I don't see
the failure to exit upon receiving the <alt><f4> key combination in Windows
without explicit code provided by the programmer as a failure of SDL. As
someone else pointed out, the programmer should provide such code (through
ifdef's if necessary).

Sam certainly has the ability to detect <alt><f4> in the low level code, and
if the underlying OS is Windows, convert it into an SDL_Quit event. It might
be a good idea, but it's not his obligation.

To be fair, I should point out that if my original post caused contention,
it's my fault. In my later years I've become exceedingly weary of
Windows-centric people thinking that they are computer experts because they
are *Windows* experts. It's like claiming to be a master chef because you've
learned how to cook spaghetti very well.

Sam has proven himself to be a master chef. Most of us have not.

Jeff
Pierre Phaneuf
2008-05-01 16:58:33 UTC
Permalink
Post by Mason Wheeler
<ALT>-<F4> is a Windows standard. It always means "quit" on every program.
Alt-F4 on Windows means "close window", not "quit". In SDL 1.2, it's
pretty much the same, but with 1.3 supporting multiple windows, it
won't be.
--
http://pphaneuf.livejournal.com/
Will Langford
2008-05-01 17:17:53 UTC
Permalink
Post by Mason Wheeler
<ALT>-<F4> is a Windows standard. It always means "quit" on every program.
While I'm not a majorly active developer in SDL at the moment, nor
very active in the mailing lists... I wouldn't mind throwing my two
cents into this foray.

Synopsis: this doesn't belong in SDL... much like many of the other
'why doesnt SDL do foo?' requests that penetrate beyond the 'SIMPLE'
part of the SDL name. If there's a desire for a nice global 'catch
all common program termination keyboard combinations', I'd suggest the
creation of SDL_quit library or similar.

Clicking on the lil X, red circle, etc etc etc, causes the window
manager or similar to give SDL an eventual SDL_QUIT message. It's
therefore up to window manager to signal the 'please close'.

I've played plenty of games under windows where ALT-F4 doesn't close
the game. And in my humble opinion it shouldn't. Granted, ALT-F4 is
a strange keyboard combination, but what if it was plausible to bind
something as such ? Similar to CTRL-number, ALT-number, etc.

If ALT-F4 is supposed to generate an SDL_QUIT under windows, then what
about lining up code that generates an SDL_QUIT via some automagical
window manager / OS detection routine and associated keyboard
combinations ? And what if I wanted to make any of those given key
combinations usable within my application rather than force a program
close ?

-Will
Sami Näätänen
2008-05-02 10:03:43 UTC
Permalink
Post by Will Langford
On Wed, Apr 30, 2008 at 6:49 PM, Mason Wheeler
Post by Mason Wheeler
<ALT>-<F4> is a Windows standard. It always means "quit" on every program.
While I'm not a majorly active developer in SDL at the moment, nor
very active in the mailing lists... I wouldn't mind throwing my two
cents into this foray.
Synopsis: this doesn't belong in SDL... much like many of the other
'why doesnt SDL do foo?' requests that penetrate beyond the 'SIMPLE'
part of the SDL name. If there's a desire for a nice global 'catch
all common program termination keyboard combinations', I'd suggest
the creation of SDL_quit library or similar.
Clicking on the lil X, red circle, etc etc etc, causes the window
manager or similar to give SDL an eventual SDL_QUIT message. It's
therefore up to window manager to signal the 'please close'.
I've played plenty of games under windows where ALT-F4 doesn't close
the game. And in my humble opinion it shouldn't. Granted, ALT-F4 is
a strange keyboard combination, but what if it was plausible to bind
something as such ? Similar to CTRL-number, ALT-number, etc.
If ALT-F4 is supposed to generate an SDL_QUIT under windows, then
what about lining up code that generates an SDL_QUIT via some
automagical window manager / OS detection routine and associated
keyboard combinations ? And what if I wanted to make any of those
given key combinations usable within my application rather than force
a program close ?
I'm with You and Bob Bendleton here. SDL should not restrict the
keyboard usage on certain platforms, because it will break portability.

SDL could have something like
SDL_EnableOSShortCuts( int bool )
to allow easy to use compatibility layer for those who want to enable
these OS specific keyboard events.
Mason Wheeler
2008-05-01 00:15:25 UTC
Permalink
Which is why I said that UNDER WINDOWS, <ALT>-<F4> should always generate SDL_QUIT. Other platforms can have other behavior.

----- Original Message ----
From: Justin Coleman <***@gmail.com>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Wednesday, April 30, 2008 4:34:42 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Justin Coleman
Post by Mason Wheeler
<ALT>-<F4> is a Windows standard.
SDL runs on more than just windows.
-Justin
Mason Wheeler
2008-05-01 03:22:13 UTC
Permalink
Windows (or any operating system) can't gracefully terminate any non-trivial program. The program has to gracefully terminate itself with its own cleanup routines to take care of allocated memory, temporary files, network connections, and howevermany other things.

----- Original Message ----
From: Jeff <***@pacbell.net>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Wednesday, April 30, 2008 8:10:16 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Jeff
<ALT>-<F4> is a Windows standard.
Which means it's not a standard. If it should be a standard *for Windows*,
then it's up to *Windows* to handle it by gracefully terminating the program.
If that's the way you want it to work, complain to Bill Gates.
Jeff
Jeff
2008-05-01 05:34:34 UTC
Permalink
Post by Mason Wheeler
Windows (or any operating system) can't gracefully terminate any
non-trivial program. The program has to gracefully terminate itself with
its own cleanup routines to take care of allocated memory, temporary files,
network connections, and howevermany other things.
Any decent OS will indeed take care of allocated memory, temp files, and other
resources used by a program when it terminates. I believe even Windows does,
but since I don't use Windows I can't say for sure.

Jeff
Sam Lantinga
2008-05-01 03:50:06 UTC
Permalink
Post by Christoph Kobe
Hi,
I've been using the SDL for one week now and I'm quite happy with it.
But there's one thing I noticed: When I press Alt-F4 to close the App it won't.
I'm catching the SDL_QUIT event, but it only occurs when I press the X to close the window, Alt-F4 won't do the job.
Strange, can you enter a bug into bugzilla for it?
http://bugzilla.libsdl.org

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
Christoph Kobe
2008-05-01 13:06:03 UTC
Permalink
On Wed, 30 Apr 2008 20:50:06 -0700
Post by Sam Lantinga
Post by Christoph Kobe
Hi,
I've been using the SDL for one week now and I'm quite happy with it.
But there's one thing I noticed: When I press Alt-F4 to close the App it won't.
I'm catching the SDL_QUIT event, but it only occurs when I press the X to close the window, Alt-F4 won't do the job.
Strange, can you enter a bug into bugzilla for it?
http://bugzilla.libsdl.org
Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
It is now Bug 576:
ALT-F4 does not generate an SDL_QUIT event on Windows
--
Christoph
from Hamburg, Germany
Mason Wheeler
2008-05-01 12:41:25 UTC
Permalink
I'm sorry, but have you ever written a program that requires any serious cleanup? Because you're beginning to sound like you haven't. Yes, the OS can deallocate a block on the heap or close files. In your other post you mentioned the Unix 'kill -9' command, which does these things. Windows has something similar, through the Task Manager. But that's forced termination without the benefit of cleanup, and there's a big difference between that and a "graceful" shutdown.

Some programs open data files with write access, and need to set them to certain states before closing or risk data loss or corruption. (Especially certain database styles! One game I have is pretty stable, and I'm glad about that because if it ever crashes you have to reinstall the whole program to fix the resulting database corruption.) Some programs open network connections to other computers and would like to let the other system know they're logging off. And if you're working directly with video memory, terminating abruptly under certain circumstances can leave it in an undefined state, with all sorts of nasty consequences for the rest of the system. These are things that the OS can't handle automatically because it doesn't know the details.

<Alt>-<F4> is not a "kill" command. It's a "close" command. It's another way to do the exact same thing as clicking the red X in the corner: send a signal through Windows's event system to the program that it's time to close the current window, which usually also means shutting down the program, unless there are other independent windows active. The program is then responsible for actually closing the window when it receives this event, giving it the chance to clean up after itself. In other words, precisely what SDL_QUIT is there for.

The original point that was made is that clicking the X button generates an SDL_QUIT event, and under Windows <Alt>-<F4> is supposed to be EXACTLY functionally equivalent to it, but it isn't because SDL grabs input away from the window controller and someone overlooked that. The Mac has something similar, the <Command>-<Q> combination, which also ought to automatically generate SDL_QUIT on a Mac. Not sure about *nix, but if it does, then that keystroke should do the same under *nix platforms. It's part of the "SDL just works" magic that makes so many of us like programming with it.

Besides, Sam's already acknowledged this as a bug. So would you mind dropping the "Windows is not God" crusading, please?

----- Original Message ----
From: Jeff <***@pacbell.net>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Wednesday, April 30, 2008 10:34:34 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Mason Wheeler
Windows (or any operating system) can't gracefully terminate any
? non-trivial program. The program has to gracefully terminate itself with
Post by Mason Wheeler
its own cleanup routines to take care of allocated memory, temporary files,
network connections, and howevermany other things.
Any decent OS will indeed take care of allocated memory, temp files, and other
resources used by a program when it terminates. I believe even Windows does,
but since I don't use Windows I can't say for sure.
Jeff
Mason Wheeler
2008-05-01 18:16:28 UTC
Permalink
----- Original Message ----
From: Will Langford <***@gmail.com>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Thursday, May 1, 2008 10:17:53 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Will Langford
Clicking on the lil X, red circle, etc etc etc, causes the window
manager or similar to give SDL an eventual SDL_QUIT message. It's
therefore up to window manager to signal the 'please close'.
That's the thing. In ordinary circumstances, <ALT>-<F4> sends the same signal. It is 100% functionally equivalent to clicking the X button, identical in every way. The only difference is that one is done with the mouse and the other is done with the keyboard.

Under SDL's input-handling scheme, however, this creates a discontinuity that shouldn't be there. If you click the mouse somewhere that's not within the window's active area (including on the frame,) the mouse click is intercepted by the window manager, not passed on the application. This is why clicking the X works. Keyboard input is handled differently. Unless what you typed is a system command, such as <ALT>-<TAB> or the Windows key, it's passed to the application automatically. <ALT>-<F4> is technically defined as the keyboard shortcut for the Close command that's present in the "system menu" of every Windows window, even fullscreen ones where the menu bar isn't visible. So pressing it invokes the Close command in the menu, which is hardwired into Windows to generate a "quit" mes
sage, exactly like clicking the X button.

Most programming schemes for creating windows work around some sort of widget set that handles input signals from the keyboard, and they give their first priority to menus because that's how a Windows program is supposed to work. SDL doesn't do this. It grabs all keyboard input if its program has input focus, and it doesn't have a widget set because it's optimized for blit-oriented game programming, not form-building. So the "menu shortcuts have priority" functionality has to be faked instead.
Post by Will Langford
I've played plenty of games under windows where ALT-F4 doesn't close
the game. And in my humble opinion it shouldn't. Granted, ALT-F4 is
a strange keyboard combination, but what if it was plausible to bind
something as such ? Similar to CTRL-number, ALT-number, etc.
If ALT-F4 is supposed to generate an SDL_QUIT under windows, then what
about lining up code that generates an SDL_QUIT via some automagical
window manager / OS detection routine and associated keyboard
combinations ? And what if I wanted to make any of those given key
combinations usable within my application rather than force a program
close ?
I can't agree with that. Conventions and standards exist for a reason, and this one has a very good reason behind it. If you don't have an arbitrarily defined and universally observed "close now" command, then the only way to quit out of a game is to select the game's own in-game close command, which is generally found in a menu somewhere. Menus aren't always accessible--during cutscenes, for example-- and sometimes it's necessary to go through several menus to find the "Exit" command. This can be a real nuisance if you need to get out of a program quickly, especially a fullscreen game. I've also played some games where <ALT>-<F4> doesn't quit, and a few where it does but doesn't quit *properly*, leaving the screen corrupted or various other nuisances. This is very bad programming and
annoys users that are used to using <ALT>-<F4> to quit, and it shouldn't be associated with SDL.
Scott Harper
2008-05-01 22:39:36 UTC
Permalink
Post by Mason Wheeler
Post by Will Langford
If ALT-F4 is supposed to generate an SDL_QUIT under windows, then what
about lining up code that generates an SDL_QUIT via some automagical
window manager / OS detection routine and associated keyboard
combinations ? And what if I wanted to make any of those given key
combinations usable within my application rather than force a program
close ?
I can't agree with that. Conventions and standards exist for a
reason, and this one has a very good reason behind it. If you don't
have an arbitrarily defined and universally observed "close now"
command, then the only way to quit out of a game is to select the
game's own in-game close command, which is generally found in a menu
somewhere. Menus aren't always accessible--during cutscenes, for
example-- and sometimes it's necessary to go through several menus
to find the "Exit" command. This can be a real nuisance if you need
to get out of a program quickly, especially a fullscreen game. I've
also played some games where <ALT>-<F4> doesn't quit, and a few
where it does but doesn't quit *properly*, leaving the screen
corrupted or various other nuisances. This is very bad programming
and annoys users that are used to using <ALT>-<F4> to quit, and it
shouldn't be associated with SDL.
I'm not sure if I'm allowed to make this argument or not, but as a
user I've always been wary of the Alt-F4 command in games, because my
general impression is that it implies a "merciless" end-program
request, and I'm pretty sure that I've NEVER wanted that feature
barring times I've played games at work, which is a no-no anyhow. ^_^
And by "merciless" I don't mean like kill -9, I mean that Windows just
assumes that you MEANT to press that key-combination. For office
applications this is likely okay.

I feel like I should point out that, even on Mac, the Command-Q
combination is a standard defined by Apple, but not ENFORCED by
Apple. It's just as easy to change the "Quit" key command to be
nothing at all, or something completely different. And case-in-point,
World of Warcraft does not recognize the Command-Q keystroke unless
you define it to have some in-game meaning, and I think this is
important. See, what happens if I'm playing your game and I try to
press Alt-4 (keeping with Warcraft, this is a default keystroke for
performing a skill), but I have fat fingers and move a little too
aggressively to the key, and manage instead to hit the F4 key?
Suddenly my game quits on me, and my party hates me, and I've gotten
quite angry and may even take steps to remove the key from my keyboard.

Gamers DO remove keys from their keyboard. For instance, back when I
used to play Final Fantasy Online (admittedly a poorly-designed game
in many technical ways) we would often remove the "Windows" key from
our keyboards because not only did it LEAVE the program, but when the
program lost front-focus, it cried like a baby and quit on you. The
Windows-key became the enemy.

Anyway, what I'm trying to say is that for normal programs, I think
yes, adhering to the standard is good. For games, I think you need to
be able to say "shove-off" to the standard. I can as easily see a
game designed that used commands Alt-F1 through Alt-F6 for a
legitimate sequence of commands, and having to work around that, were
the ability you're describing to be built into SDL, that would provide
a lot of excess work specifically for the Windows port of the game,
wouldn't it?

Isn't it just simpler to use "#ifdef __WINDOWS" or whatever the
Windows identifier is to capture Alt-F4 if that's a feature you want
to support, rather than forcing other non-Windows developers to
redesign their keyboard command interface (which is completely
legitimate on Linux AND Mac) for the Windows version, or add what I
could only imagine to likely be excess code to work AROUND the Alt-F4
check in the Windows version of their software?

-- Scott

On a side note, you mentioned a game which you said is fortunately
very stable, because were it to crash you would have to reinstall the
game, as your data would be corrupt. As a user and gamer myself, this
scares the living you-know-what out of me. I would probably never
even TRY playing a game if I heard this about it, because there are a
LOT of things OTHER than the game itself which can cause a crash,
including cats, electrical storms, hot coffee or other drinks), faulty
power-supplies, problems with motherboard/video cards, etc... Even as
a relatively inexperienced developer, though, I have to believe that
there's a better way to store game data that doesn't force you to
reinstall the ENTIRE game if something crashes and/or gets corrupted.
Speaking as a mere user again, this sounds to me like an INCREDIBLY
bad design decision.

Anyway, my $.02.
Mason Wheeler
2008-05-01 22:47:35 UTC
Permalink
----- Original Message ----
From: Scott Harper <***@gmail.com>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Thursday, May 1, 2008 3:39:36 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Scott Harper
See, what happens if I'm playing your game and I try to
press Alt-4 (keeping with Warcraft, this is a default keystroke for
performing a skill), but I have fat fingers and move a little too
aggressively to the key, and manage instead to hit the F4 key?
Suddenly my game quits on me, and my party hates me, and I've gotten
quite angry and may even take steps to remove the key from my keyboard.
This is why a well-designed game (or any application in which data loss might be an issue) will prompt you if you really want to quit, and/or if you want to save before quitting. That's the nice thing about the idea of a graceful shutdown, as opposed to outright program termination: It can be cancelled. Most Windows and Mac games are pretty well-behaved about this. If you hit <ALT>-<F4> or <Command>-Q, it asks if you really want to quit. If you say yes, then it begins to shut down. If an online game dumps you back into Windows and ruins your party because you hit the wrong key on accident, then yes, the programmers screwed up, but their mistake wasn't adhering to established standards.
Tim Goya
2008-05-01 23:07:51 UTC
Permalink
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.

Tim
Bill Kendrick
2008-05-02 16:06:23 UTC
Permalink
Post by Tim Goya
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.
Time for an API to let the programmer decide! :) (and/or env vars)
--
-bill!
***@newbreedsoftware.com
http://www.newbreedsoftware.com/
Torsten Giebl
2008-05-02 16:13:05 UTC
Permalink
Hello !
Post by Bill Kendrick
Time for an API to let the programmer decide! :) (and/or env vars)
Jup. I never thought that a discussion about ALT F4 and
SDL would be so long :-)


CU
Mason Wheeler
2008-05-01 23:19:12 UTC
Permalink
Hoo boy. Things always get muddled when people bring up words like "freedom" in the context of software development. My take on this is, creative freedom is nice, but it *definitely* needs to be restricted, because the most important freedom of all is the right of the computer's owner to have the computer do what he or she intends for it to do. If you legitimize the practice of taking absolute control of the computer out of its owner's hands, even in games, you make it that much easier for truly scary stuff like TC to get its foot in the door.

----- Original Message ----
From: Tim Goya <***@gmail.com>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Thursday, May 1, 2008 4:07:51 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Tim Goya
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.
Tim
Bob Pendleton
2008-05-01 23:41:21 UTC
Permalink
Hoo boy, this takes me back. I was involved in the port of Doom II to the
Mac back in the middle 90s.... Of course, Doom and all of its decedents use
the mouse to move you forward and backward and to turn left and right. It
turns out that that use of the mouse was forbidden by the Apple usability
guidelines. There Mac fans up in arms over the failure to comply with the
holy word as writ by by great lord Mac. We got flamed left and right. Oh my.
OTOH none of those Mac fans could tell us any other way to navigate in the
game. We asked what they thought we should do and the result was "comply
with the guidelines". Of course, the guidelines were written without any
consideration for how you would use a mouse in a first person shooter so the
guidelines were useless.

What it came down to is that you had to violate the guidelines to implement
the game. Letting some companies guidelines or even their hard and fast
rules interfere with game design is like refusing to change your mind when
faced with new evidence. It doesn't make sense. Sure, you have to balance
design against social norms, but you need not be, and in some cases must not
be, controlled by the norms. If my design works best when I give some
meaning to alt-f1 through alt-f10 then I should be able to implement that
without having to change the source code of SDL to do it. IMHO, SDL should
allow you to conform to the norms of your system if you chose to. It must
not enforce the norms of a particular system. And, most importantly, it must
not do things like making alt-f4 == SDL_QUIT on windows but not on Mac or
LInux or whatever else I want to code for.

Oh well, that is one of the many things I learned from working on that port.
Another is to never never never call functions with side effects in the
argument list of other functions. :-) Oh, and BSP trees are cool but hard to
debug.

Bob Pendleton
Post by Mason Wheeler
Hoo boy. Things always get muddled when people bring up words like
"freedom" in the context of software development. My take on this is,
creative freedom is nice, but it *definitely* needs to be restricted,
because the most important freedom of all is the right of the computer's
owner to have the computer do what he or she intends for it to do. If you
legitimize the practice of taking absolute control of the computer out of
its owner's hands, even in games, you make it that much easier for truly
scary stuff like TC to get its foot in the door.
----- Original Message ----
To: A list for developers using the SDL library. (includes SDL-announce) <
Sent: Thursday, May 1, 2008 4:07:51 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Tim Goya
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.
Tim
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
+ Bob Pendleton: writer and programmer
+ email: ***@Pendleton.com
+ web: www.GameProgrammer.com
+ www.Wise2Food.com

+--------------------------------------+
Torsten Giebl
2008-05-02 00:01:30 UTC
Permalink
Hello !


Personally i like it that ALT F4 on Windows, Apple Q on Mac OSX and
so on generate a WM_QUIT with SDL. That way i don't have to ask the
user, what QUIT key do you wan to use.

When you get an WM_QUIT event, you can still ask the user what to do next.


CU
Mason Wheeler
2008-05-02 11:26:34 UTC
Permalink
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. And as you pointed out, there's no other good way to control an FPS. What you did enhanced the players' experience without any true drawbacks, simply by ignoring an outdated rule that needed to be updated.

Here, we're talking about the right of a computer owner to quit any program at any time. This is a fundamental right and must be held absolutely sacred. If you violate it, you're taking control of the computer out of its owners' hands. In other words, you're writing malware. The line here isn't "there's no alternative", it's "there's no excuse." Interface considerations are secondary, and key combinations can be altered just a little bit to keep from b0rking one very important command that's been in place forever and then some.


----- Original Message ----
From: Bob Pendleton <***@pendleton.com>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Thursday, May 1, 2008 4:41:21 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Hoo boy, this takes me back. I was involved in the port of Doom II to the Mac back in the middle 90s....
Of course, Doom and all of its decedents use the mouse to move you forward and backward and to turn left
and right. It turns out that that use of the mouse was forbidden by the Apple usability guidelines. There Mac
fans up in arms over the failure to comply with the holy word as writ by by great lord Mac. We got flamed
left and right. Oh my. OTOH none of those Mac fans could tell us any other way to navigate in the game.
We asked what they thought we should do and the result was "comply with the guidelines". Of course, the
guidelines were written without any consideration for how you would use a mouse in a first person shooter
so the guidelines were useless.
Graham Houston
2008-05-02 12:46:13 UTC
Permalink
Post by Mason Wheeler
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. And as you pointed out, there's no
other good way to control an FPS. What you did enhanced the players'
experience without any true drawbacks, simply by ignoring an outdated
rule that needed to be updated.
Here, we're talking about the right of a computer owner to quit any
program at any time. This is a fundamental right and must be held
absolutely sacred. If you violate it, you're taking control of the
computer out of its owners' hands. In other words, you're writing
malware. The line here isn't "there's no alternative", it's "there's no
excuse." Interface considerations are secondary, and key combinations
can be altered just a little bit to keep from b0rking one very important
command that's been in place forever and then some.
and is left to the developer to implement! it should not be default, I've
ALT+F4
mapped to other uses in a few games I've developed and this is the point
of SDL
you can do what you like. If ALT+F4 was to do what is intended by the OS
then I'd
have all sorts of problems having to undo it.

You said yourself apples and oranges...
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Bill Kendrick
2008-05-02 16:12:17 UTC
Permalink
Post by Mason Wheeler
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.
*cough* http://en.wikipedia.org/wiki/Star_Raiders

;)

-bill!
Mason Wheeler
2008-05-02 13:00:44 UTC
Permalink
It's left for the developer to implement as a graceful shutdown command, because there's no way
for the OS do to it for the program. It's reserved and should not be used for anything else, because
to do so violates the computer owner's rights.

Your right to be "creative" and to "do what you want" ENDS where your users' right to control their
own computer begins. It's that simple.

----- Original Message ----
From: Graham Houston <***@rushpark.co.uk>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Friday, May 2, 2008 5:46:13 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Graham Houston
and is left to the developer to implement! it should not be default, I've
ALT+F4 mapped to other uses in a few games I've developed and this is the point
of SDL you can do what you like. If ALT+F4 was to do what is intended by the OS
then I'd have all sorts of problems having to undo it.
You said yourself apples and oranges...
Sami Näätänen
2008-05-02 13:22:29 UTC
Permalink
Post by Mason Wheeler
It's left for the developer to implement as a graceful shutdown
command, because there's no way for the OS do to it for the program.
It's reserved and should not be used for anything else, because to do
so violates the computer owner's rights.
No it does not.
And I for one would not want any game to quit when I press Alt+F4.
And for other programs that could be done easily. I would agree that it
would be nice to have an easy OS independent way to enable OS specific
shortcuts, but forcing those would be silly.
Post by Mason Wheeler
Your right to be "creative" and to "do what you want" ENDS where your
users' right to control their own computer begins. It's that simple.
No it's up to the users to agree what you have chosen to do or to not
use your creations.
Graham Houston
2008-05-02 13:24:41 UTC
Permalink
Post by Mason Wheeler
It's left for the developer to implement as a graceful shutdown command,
because there's no way
for the OS do to it for the program. It's reserved and should not be
used for anything else, because
to do so violates the computer owner's rights.
Your right to be "creative" and to "do what you want" ENDS where your
users' right to control their
own computer begins. It's that simple.
Mason sometimes you have good reason not to do something that everything
else does
for example: I'm in the middle of a FPS game say Quake and I want to
change weapon,
now the weapon selects are keys are 1-9 if I reach for the 3 key I can
easly over-reach
and hit the F4 key not good when I use the ALT key for firing the weapon!!

Graham
Post by Mason Wheeler
----- Original Message ----
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Friday, May 2, 2008 5:46:13 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Graham Houston
and is left to the developer to implement! it should not be default, I've
ALT+F4 mapped to other uses in a few games I've developed and this is the point
of SDL you can do what you like. If ALT+F4 was to do what is intended by the OS
then I'd have all sorts of problems having to undo it.
You said yourself apples and oranges...
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Bob Pendleton
2008-05-02 13:26:49 UTC
Permalink
Mason, take a deep breath and relax.

You have now wrapped your self up in human rights, mom, the flag, and apple
pie. That is, you are working very hard to paint your self into a corner so
tightly that you can not back down. Please, just call us all Nazis so we can
invoke Godwin's law, have a good laugh and get on with life...

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.

Tools, not rules.

Bob Pendleton
Post by Mason Wheeler
It's left for the developer to implement as a graceful shutdown command,
because there's no way
for the OS do to it for the program. It's reserved and should not be used
for anything else, because
to do so violates the computer owner's rights.
Your right to be "creative" and to "do what you want" ENDS where your
users' right to control their
own computer begins. It's that simple.
----- Original Message ----
To: A list for developers using the SDL library. (includes SDL-announce) <
Sent: Friday, May 2, 2008 5:46:13 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Graham Houston
and is left to the developer to implement! it should not be default, I've
ALT+F4 mapped to other uses in a few games I've developed and this is the
point
Post by Graham Houston
of SDL you can do what you like. If ALT+F4 was to do what is intended by
the OS
Post by Graham Houston
then I'd have all sorts of problems having to undo it.
You said yourself apples and oranges...
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
+ Bob Pendleton: writer and programmer
+ email: ***@Pendleton.com
+ web: www.GameProgrammer.com
+ www.Wise2Food.com

+--------------------------------------+
Bill Kendrick
2008-05-02 16:18:17 UTC
Permalink
Post by Bob Pendleton
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.
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. :)

-bill!
Graham Houston
2008-05-02 16:25:51 UTC
Permalink
Post by Bill Kendrick
Here is, I think, the problem.
On my KDE desktop, ALT+F4 closes windows.
And on my KDE destop <<CTRL>>+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?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Mason Wheeler
2008-05-02 13:36:09 UTC
Permalink
I'm sorry, but this is something I feel very strongly about. We've got Microsoft and a handful of other corporations who have demonstrated, time and time again, that they do not have users' best interests at heart, working on putting TC into everyone's computers as a standard "feature," which--long propaganda articles about "improved security" notwithstanding--is designed to transfer fine control of the computer from the owner to the programmer. When you consider how much of our modern society is dependent on computer systems, that DOES come pretty darn close to being a human rights violation, and I get a bit touchy about anything that legitimizes the practice in any way.


----- Original Message ----
From: Bob Pendleton <***@pendleton.com>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Friday, May 2, 2008 6:26:49 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Bob Pendleton
Mason, take a deep breath and relax.
You have now wrapped your self up in human rights, mom, the flag, and apple pie. That is, you are >working very hard to paint your self into a corner so tightly that you can not back down. Please, just
call us all Nazis so we can invoke Godwin's law, have a good laugh and get on with life...
Bob Pendleton
2008-05-02 13:42:37 UTC
Permalink
Ah... I understand that point of view very well. Let me just point out one
thing I think you got wrong. It isn't about transferring control from the
user to the programmer. It is all about transferring control from the user
to the corporation. Programmers at MS are not getting any more control
through their efforts for MS. The top two or three people who *run* MS are
getting the control. Same goes for all big corporations. The little guys are
just grunts, the top guys get all the power and all the money.

SDL helps little guys build software that is not under the control of anyone
but the little guys.

Bob Pendleton
Post by Mason Wheeler
I'm sorry, but this is something I feel very strongly about. We've got
Microsoft and a handful of other corporations who have demonstrated, time
and time again, that they do not have users' best interests at heart,
working on putting TC into everyone's computers as a standard "feature,"
which--long propaganda articles about "improved security"
notwithstanding--is designed to transfer fine control of the computer from
the owner to the programmer. When you consider how much of our modern
society is dependent on computer systems, that DOES come pretty darn close
to being a human rights violation, and I get a bit touchy about anything
that legitimizes the practice in any way.
----- Original Message ----
To: A list for developers using the SDL library. (includes SDL-announce) <
Sent: Friday, May 2, 2008 6:26:49 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Bob Pendleton
Mason, take a deep breath and relax.
You have now wrapped your self up in human rights, mom, the flag, and
apple pie. That is, you are >working very hard to paint your self into a
corner so tightly that you can not back down. Please, just
Post by Bob Pendleton
call us all Nazis so we can invoke Godwin's law, have a good laugh and get
on with life...
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
+ Bob Pendleton: writer and programmer
+ email: ***@Pendleton.com
+ web: www.GameProgrammer.com
+ www.Wise2Food.com

+--------------------------------------+
Mason Wheeler
2008-05-02 13:47:53 UTC
Permalink
----- Original Message ----
From: Bob Pendleton <***@pendleton.com>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Friday, May 2, 2008 6:42:37 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Ah... I understand that point of view very well. Let me just point out one thing I think you got wrong.
It isn't about transferring control from the user to the programmer. It is all about transferring control
from the user to the corporation. Programmers at MS are not getting any more control through their
efforts for MS. The top two or three people who *run* MS are getting the control. Same goes for
all big corporations. The little guys are just grunts, the top guys get all the power and all the money.
I understand, and that's what I meant. In the practical sense, Microsoft's programs are "written by Microsoft," not by John Q. Microserf.
SDL helps little guys build software that is not under the control of anyone but the little guys.
That's the thing. Software should be under the control of the user, not the programmer, whether or not the programmer belongs to an evil megacorporation.
KHMan
2008-05-02 14:12:10 UTC
Permalink
Post by Mason Wheeler
----- Original Message ----
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Friday, May 2, 2008 6:42:37 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Bob Pendleton
Ah... I understand that point of view very well. Let me just point out
one thing I think you got wrong.
Post by Bob Pendleton
It isn't about transferring control from the user to the programmer. It
is all about transferring control
Post by Bob Pendleton
from the user to the corporation. Programmers at MS are not getting any
more control through their
Post by Bob Pendleton
efforts for MS. The top two or three people who *run* MS are getting
the control. Same goes for
Post by Bob Pendleton
all big corporations. The little guys are just grunts, the top guys get
all the power and all the money.
I understand, and that's what I meant. In the practical sense,
Microsoft's programs are "written by Microsoft," not by John Q. Microserf.
Post by Bob Pendleton
SDL helps little guys build software that is not under the control of
anyone but the little guys.
That's the thing. Software should be under the control of the user, not
the programmer, whether or not the programmer belongs to an evil
megacorporation.
The trouble with this long thread is, some of us are discussing it
from the purely engineering standpoint and the two sides will
probably have to agree to disagree to some extent.

IMHO, a developer should not be forcibly limited to something that
is recommended UI behaviour for what is usually windowed
applications. Of course this isn't anywhere ideal for a developer
with your views, but the fact is that a developer has always been
able to do almost any kind of wrong or non-standard thing with a
Win32 message loop. And SDL is a low-level layer.

IMHO, something that forcibly enforces UI recommendations should
be optional or live in a separate layer. Elsewhere others have
mentioned that there are apps that need control over Alt-F4.
Virtual PC, for example, needs to and does keep control of Alt-F4,
Alt-Tab, etc., all those recommended standard UI keystrokes.

I trust Sam will do the right thing. Just a cheap USD0.02. :-)
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
Pierre Phaneuf
2008-05-02 15:21:15 UTC
Permalink
Post by KHMan
Virtual PC, for example, needs to and does keep control of Alt-F4,
Alt-Tab, etc., all those recommended standard UI keystrokes.
That reminds me of one of the original SDL-using application (if not
the first?): an emulator that probably needed to do just that. :-)
--
http://pphaneuf.livejournal.com/
KHMan
2008-05-02 14:58:03 UTC
Permalink
Post by Mason Wheeler
----- Original Message ----
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Friday, May 2, 2008 6:42:37 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
[snipped all]
I apologize in advance for prolonging this, but I tried to do a
search, all I found was the following (anyone have more useful
links to share?):

End users:
http://www.microsoft.com/enable/products/keyboard.aspx
http://support.microsoft.com/kb/126449
http://support.microsoft.com/kb/301583

MSDN:
http://msdn.microsoft.com/en-us/library/bb545461.aspx

For the MSDN page: Unfortunately it's pretty vague and ambiguous
if we try to apply those rules in a strict fashion to applications
like games or emulators. The rules implies a certain degree of
similarity to windowed applications that deal with documents. So
who or how do we decide which shortcut combination is mandatory
for unconventional full-screen apps? Looking at the document, it's
unclear to me why Alt-F4 is singled out as special, something that
must be relied upon to work for all apps.
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
Mason Wheeler
2008-05-02 16:28:21 UTC
Permalink
----- Original Message ----
From: Graham Houston <***@rushpark.co.uk>
To: A list for developers using the SDL library. (includes SDL-announce) <***@lists.libsdl.org>
Sent: Friday, May 2, 2008 9:25:51 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Graham Houston
And on my KDE destop <<CTRL>>+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.
Graham Houston
2008-05-02 16:33:10 UTC
Permalink
Post by Mason Wheeler
----- Original Message ----
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
Post by Graham Houston
And on my KDE destop <<CTRL>>+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!
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Erik
2008-05-02 17:06:40 UTC
Permalink
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
David Olsen
2008-05-02 20:12:49 UTC
Permalink
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
René Dudfield
2008-05-02 20:37:02 UTC
Permalink
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 :)


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
Pierre Phaneuf
2008-05-03 00:11:24 UTC
Permalink
Post by René Dudfield
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 :)
How about for a program that is in windowed mode rather than fullscreen?
--
http://pphaneuf.livejournal.com/
Graham Houston
2008-05-03 00:23:52 UTC
Permalink
Post by Pierre Phaneuf
Post by René Dudfield
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 :)
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 [x] icon either, you have to trap it and write the quit
routine yourself... just like the ALT-F4 key combo!!!


Graham.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Scott Harper
2008-05-03 01:48:52 UTC
Permalink
Post by Graham Houston
Post by Pierre Phaneuf
Post by René Dudfield
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 :)
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 [x] 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
Will Langford
2008-05-03 04:50:35 UTC
Permalink
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 :) (even from a non-security
stand point).
Rainer Deyke
2008-05-03 05:37:29 UTC
Permalink
Post by Will Langford
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 - ***@eldwood.com
Rainer Deyke
2008-05-03 02:06:22 UTC
Permalink
Post by René Dudfield
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 :)
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 - ***@eldwood.com
Christoph Kobe
2008-05-03 15:49:27 UTC
Permalink
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
Graham Houston
2008-05-03 15:59:30 UTC
Permalink
Post by Christoph Kobe
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 [X] 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.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Christoph Kobe
2008-05-03 16:23:53 UTC
Permalink
On Sat, 03 May 2008 16:59:30 +0100
Post by Graham Houston
Post by Christoph Kobe
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 [X] 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.
Post by Graham Houston
if ALT-F4 caused the SDL_QUIT event then how do you tell the difference
between a SDL_QUIT that was caused by the [X] 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 [X] 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, [X], Taskmanager, etc.) but all a windows program gets is the WM_DESTROY message.
Post by Graham Houston
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.
Post by Graham Houston
Graham.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
--
Christoph
from Hamburg, Germany
Graham Houston
2008-05-03 16:36:21 UTC
Permalink
Post by Christoph Kobe
On Sat, 03 May 2008 16:59:30 +0100
On Sat, 03 May 2008 16:49:27 +0100, Christoph Kobe
Post by Christoph Kobe
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 [X] 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 [X] 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 [X] 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, [X],
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/
Christoph Kobe
2008-05-03 16:47:43 UTC
Permalink
On Sat, 03 May 2008 17:36:21 +0100
Post by Graham Houston
Post by Christoph Kobe
On Sat, 03 May 2008 16:59:30 +0100
On Sat, 03 May 2008 16:49:27 +0100, Christoph Kobe
Post by Christoph Kobe
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 [X] 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 [X] 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 [X] 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, [X],
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!!
You could as well try to use ALT-TAB or CTRL-ALT-DEL in your application but these are pre-defined key in windows and as well is ALT-F4. It's very poor design using ALT-F4 on windows for anything else than quitting the program.
Post by Graham Houston
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.
My main question still is: Why is ALT-F4 in the SDL not generating a WM_DESTROY event? With every other program this is working fine, so there has to be something that prevents the event. I'm not insisting that this is a bug (although I think so) but I'm asking WHY.
Post by Graham Houston
Graham.
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
--
Christoph
from Hamburg, Germany
Graham Houston
2008-05-03 16:57:47 UTC
Permalink
Post by Christoph Kobe
On Sat, 03 May 2008 17:36:21 +0100
On Sat, 03 May 2008 17:23:53 +0100, Christoph Kobe
Post by Christoph Kobe
On Sat, 03 May 2008 16:59:30 +0100
On Sat, 03 May 2008 16:49:27 +0100, Christoph Kobe
Post by Christoph Kobe
What part of the SDL does actually prevent the WM_DESTROY event
that
Post by Christoph Kobe
Post by Christoph Kobe
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
Post by Christoph Kobe
event if you hit ALT-F4 or if you press the [X] icon. If you were
right
Post by Christoph Kobe
every other windows program would have to catch keyboard events and
look
Post by Christoph Kobe
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
Post by Christoph Kobe
between a SDL_QUIT that was caused by the [X] icon and the key combo?
This is true, you would not be able to tell the difference from the
view
Post by Christoph Kobe
of the SDL app. But why should one care how the Program closes? I
think
Post by Christoph Kobe
you can't tell either if your program was terminated by clicking [X]
or
Post by Christoph Kobe
by using the task manager to terminate the process. But that's the
point, there are several ways to terminate a Program (ALT-F4, [X],
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
Post by Christoph Kobe
ALT-F4 to close the app/game then just catch the key combo and do
what
Post by Christoph Kobe
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
Post by Christoph Kobe
be different from ALT-F4.
And if I want ALT-F4 on Windows to not close the window but do something
else ?? im buggered!!
You could as well try to use ALT-TAB or CTRL-ALT-DEL in your application
but these are pre-defined key in windows and as well is ALT-F4. It's
very poor design using ALT-F4 on windows for anything else than quitting
the program.
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.
My main question still is: Why is ALT-F4 in the SDL not generating a
WM_DESTROY event? With every other program this is working fine, so
there has to be something that prevents the event. I'm not insisting
that this is a bug (although I think so) but I'm asking WHY.
perhaps the developers realised this would break existing code that
expects ALT-F4 to not generate WM_DESTROY? I don't know? but I do use
ALT-F4 in some apps I've developed to do other things and right or wrong
if it was changed my code would not function as intended...

I do see your point regarding Windows apps always generating WM_DESTROY on
the combo, but I guess this can be changed even in non SDL applications to
do what you want. So way break existing code by changing the behaviour and
leaving less room for options??


Graham
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Will Langford
2008-05-03 20:23:23 UTC
Permalink
Hmm... btw... I have to take a quick stab at the RIGHTS issue
flamebait with my own flamebait remark.

The user is given the RIGHT to use whatever program they're running,
they are not entitled to it :). Extend this argument to EULA's,
public domain, GPL, they don't HAVE to use the program, etc etc etc
:). Then, continuing the 'RIGHTS' argument, most agreements include
clauses stating no fitness of purpose, indemnity, warranty, guarantee,
etc etc etc. If you're going to insist the user has a RIGHT to common
OS/WM controls, then does not implementing them mean apps that don't
support them fall under malware, viruses, abusive, etc ?

I'd skip the whole rights issue and focus on where it should be
implemented in the design aspect of things :). I, personally, dislike
an extra layer in the event pipeline, but, having the WM part of SDL,
or an SDL_wmconvention library offer an _Init() or something seems the
most plausible. Then you get the fun of if() vs function pointer
goodness, etc etc etc. And, best of all, I'd imagine it'd only take
an hour or three to implement such a system... meaning we'd have a
stop-gap solution in the interim. I, sadly, have a 24/7 on call life,
and therefore don't have time to implement it personally :(.

I wouldn't mind seeing something available to catch these common OS/WM
commands to aid in cross platform goodness... although having them
forced down your throat would undoubtedly have ALOT of people up in
arms.

Back to securing a server, blech :(.

-Will
Bill Kendrick
2008-05-03 23:47:13 UTC
Permalink
Post by Graham Houston
And if I want ALT-F4 on Windows to not close the window but do something
else ?? im buggered!!
Holy crap, people. Can't we all just get along? And by "get along,"
I mean: I suggest we DO have SDL support ALT+F4 keypresses. It keeps MY life
simple. (I don't have to add "#ifdef WINDOWS if (event.type == yadayada...)"
in every event loop of every app, when I'm _already_ doing
"if (event.type == SDL_QUIT)")

For those of you who feel 'buggered' by adding this functionality to SDL,
which, again, I feel _keeps programmers' lives simple_, we should add an
API or env var that determines whether SDL listens out for ALT+F4 on Windows
(and whatever else some OS might dream up that it'd be a kluge to handle
in our own code).
Post by Graham Houston
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!!
This is why, for historical/compatibility reasons, at least under SDL 1.2,
the _default_ behavior should be: "pass the ALT+F4 along to the event queue
as keypresses." The _enhanced_ behavior, which 99% of people would want
to enable, should be "listen for ALT+F4 on Windows and send SDL_QUIT event".
Post by Graham Houston
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.
Or... let SDL do that for us, so that three lines of #ifdef'd code doesn't
need to pollute everyone's app-level code. :D
--
-bill!
***@newbreedsoftware.com
http://www.newbreedsoftware.com/
Bob Pendleton
2008-05-04 00:03:20 UTC
Permalink
Can we just drop this whole thing? Seriously, this is too weird to
believe....

No? Ok, everyone who disagrees with me is a NAZI!

Now, I invoke Godwin's law and proclaim this over and moot. :-)

Bob Pendleton
Post by Bill Kendrick
Post by Graham Houston
And if I want ALT-F4 on Windows to not close the window but do something
else ?? im buggered!!
Holy crap, people. Can't we all just get along? And by "get along,"
I mean: I suggest we DO have SDL support ALT+F4 keypresses. It keeps MY life
simple. (I don't have to add "#ifdef WINDOWS if (event.type ==
yadayada...)"
in every event loop of every app, when I'm _already_ doing
"if (event.type == SDL_QUIT)")
For those of you who feel 'buggered' by adding this functionality to SDL,
which, again, I feel _keeps programmers' lives simple_, we should add an
API or env var that determines whether SDL listens out for ALT+F4 on Windows
(and whatever else some OS might dream up that it'd be a kluge to handle
in our own code).
Post by Graham Houston
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
Post by Graham Houston
as expected.. instead of doing what was intended of the combo it quits
the
Post by Graham Houston
program!!! this would be a bug!!
This is why, for historical/compatibility reasons, at least under SDL 1.2,
the _default_ behavior should be: "pass the ALT+F4 along to the event queue
as keypresses." The _enhanced_ behavior, which 99% of people would want
to enable, should be "listen for ALT+F4 on Windows and send SDL_QUIT event".
Post by Graham Houston
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.
Or... let SDL do that for us, so that three lines of #ifdef'd code doesn't
need to pollute everyone's app-level code. :D
--
-bill!
http://www.newbreedsoftware.com/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
+ Bob Pendleton: writer and programmer
+ email: ***@Pendleton.com
+ web: www.GameProgrammer.com
+ www.Wise2Food.com

+--------------------------------------+
Will Langford
2008-05-04 00:04:57 UTC
Permalink
Post by Bill Kendrick
Or... let SDL do that for us, so that three lines of #ifdef'd code doesn't
need to pollute everyone's app-level code. :D
Possibly replaced with a single environment push or similar disabling call :).

Obviously there's been enough of a fervor to implement this thing, but
I'd really like to see it as either optional or disable-able (take
your connotative pick depending on which side of the fence you're on
heh). Hopefully it's done in a modular way to make other OS/WM
support easy, and with the possibility of other hooks for similar
desires (outside of just program exit... there might be other traps
needed such as iconify/fullscreen).

The fun comes in how to deal with different window managers on less
restrictive systems (unixes). I imagine they might present
alternative command sets for things, so making it a compile time
option might not fit some platforms... and then attempting to
automagically determine your window manager might yield some fun.
Granted, an immediate solution for Win/Mac is easy enough.

-Will
Pierre Phaneuf
2008-05-04 00:43:32 UTC
Permalink
Post by Bill Kendrick
Holy crap, people. Can't we all just get along? And by "get along,"
I mean: I suggest we DO have SDL support ALT+F4 keypresses. It keeps MY life
simple. (I don't have to add "#ifdef WINDOWS if (event.type == yadayada...)"
in every event loop of every app, when I'm _already_ doing
"if (event.type == SDL_QUIT)")
Traditionally, in GUI toolkit, what happens is that either the
application provides a callback to the toolkit that gets called for
each messages and returns whether the application handled the message
or not, or there is a "get message" function, and an application is
supposed to call some "dispatch message" if it's not a message that it
found "interesting" (i.e. it didn't handle it). SDL does *not* provide
this mechanism: either the application handles the message, or it's
dropped on the floor without further processing.

If I remember correctly, what happens on Windows is that the
application gets the Alt-F4 key pressed (well, okay, released,
actually, if I'm not mistaken, but you get the idea) message, and if
you want to do something with it, you do so, and don't call
DispatchMessage. If your application didn't handle it and calls
DispatchMessage, it will post itself a WM_DESTROY (or WM_CLOSE? I
don't remember) message, which the application will then shortly
receive.

IMHO, the *real* bug is that SDL doesn't have this structure that
usually handles that case, making it just plain hard in general to
"fit in" and forcing applications to re-implement those default
behaviours itself, and often in weird ways (the game I work on,
Quadra, quits with Alt-F4 on every platforms!).

Note that someone used to Xlib programming might think that this is
incorrect (there is no equivalent to DispatchEvent in Xlib), but it's
just that Xlib is at lower level. The morally equivalent layer would
be Xt (among others, X11 is well known for giving a lot of choices,
for better or for worse), where you will find that an application does
XtAppNextEvent and XtAppDispatchEvent.
--
http://pphaneuf.livejournal.com/
Sam Lantinga
2008-05-04 01:20:44 UTC
Permalink
Alt-F4 not generating an SDL_QUIT event on Windows is a bug and has been
entered into bugzilla. It will be fixed for the next release.

'nuff said.

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
René Dudfield
2008-05-05 04:42:06 UTC
Permalink
This will break a common windows game convention of using the F*
buttons for game actions, and will also make cross platform games
harder to write.

It will also break behaviour of past games and applications that
relied on ALT+F4 not quitting.

What is the work around for those not wanting this behaviour?

Is this change happening in the 1.3 or 1.2 series?
Post by Sam Lantinga
Alt-F4 not generating an SDL_QUIT event on Windows is a bug and has been
entered into bugzilla. It will be fixed for the next release.
'nuff said.
Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Max Horn
2008-05-05 07:15:43 UTC
Permalink
Ahh, the good old bikeshed debate...

<http://www.bikeshed.com/>

Seriously: It's certainly OK to discuss this (mis)feature, but this
thread has totally lost proportion to the importance of this subject
*sigh*.

Bye,
Max
Will Langford
2008-05-05 07:24:15 UTC
Permalink
Post by René Dudfield
This will break a common windows game convention of using the F*
buttons for game actions, and will also make cross platform games
harder to write.
It will also break behaviour of past games and applications that
relied on ALT+F4 not quitting.
What is the work around for those not wanting this behaviour?
Is this change happening in the 1.3 or 1.2 series?
Trying to argue for or against the functionality is futile.
Decision's been made :).

I'd trust he wouldn't make it a
no-option-but-to-follow-this-hard-set-behavior patch. They'll let us
know how it's implemented and how to tune the behavior (if
applicable).... and hopefully have some kind of mention of where to
poke around to add similar support for the behavior on other platforms
:).

My only concern left is updating a system library / DLL out from under
an existing closed source app that expects to not have the
functionality on by default. But... how many closed source SDL apps
are there anyway ? And do they package their own SDL library in their
path so as to not use the system one if provided, etc ... making this
a moot concern ?

-Will
Christian Walther
2008-05-04 13:19:38 UTC
Permalink
Post by Pierre Phaneuf
Traditionally, in GUI toolkit, what happens is that either the
application provides a callback to the toolkit that gets called for
each messages and returns whether the application handled the message
or not, or there is a "get message" function, and an application is
supposed to call some "dispatch message" if it's not a message that it
found "interesting" (i.e. it didn't handle it). SDL does *not* provide
this mechanism: either the application handles the message, or it's
dropped on the floor without further processing.
If I remember correctly, what happens on Windows is that the
application gets the Alt-F4 key pressed (well, okay, released,
actually, if I'm not mistaken, but you get the idea) message, and if
you want to do something with it, you do so, and don't call
DispatchMessage. If your application didn't handle it and calls
DispatchMessage, it will post itself a WM_DESTROY (or WM_CLOSE? I
don't remember) message, which the application will then shortly
receive.
That's an idea that has occurred to me as well at one point, in the
context of handling menu keyboard equivalents on Mac OS. My application
is cross-platform for the most part, but has a Mac-specific part that
sets up and handles a Cocoa menu bar. Some menu items in there have
keyboard equivalents, but they don't work unless I check for them
manually in my SDL event handling. It would be nice to have an
SDL_PassEvent() function or something that could be called when the
application wants to pass an event that it doesn't want to handle itself
back to the OS, where, on Mac OS, a key event would eventually be
matched against the menu keyboard equivalents. (I totally agree with
everyone that the application needs to get a chance to process a key
event itself first, before it is eaten up by the keyboard equivalent
handling of the OS (or windowing toolkit or window manager or whatever).)

I have no idea how easy this would be to implement on different
platforms, though.

I have no particular opinion on the immediate Alt-F4 issue at hand. Just
wanted to express my interest in an idea that may be worth looking into
for SDL 3 or something. :)

-Christian
Mason Wheeler
2008-05-03 17:46:01 UTC
Permalink
----- Original Message ----
From: Christoph Kobe <***@kobenetz.de>
To: ***@libsdl.org
Sent: Saturday, May 3, 2008 9:47:43 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Christoph Kobe
My main question still is: Why is ALT-F4 in the SDL not generating a WM_DESTROY event? With every
other program this is working fine, so there has to be something that prevents the event. I'm not insisting
that this is a bug (although I think so) but I'm asking WHY.
Because SDL hooks the keyboard input at a low enough level that it receives the keypresses before the window manager does. <ALT>-<F4> is defined as a menu shortcut for the Close command in the window's system menu, and then the Close command generates a WM_DESTROY message. But since the window manager never gets the keypress, the shortcut can't be activated. (Opening the system menu with the mouse and selecting Close works just fine.)
Christoph Kobe
2008-05-03 18:16:23 UTC
Permalink
On Sat, 3 May 2008 10:46:01 -0700 (PDT)
Post by Mason Wheeler
----- Original Message ----
Sent: Saturday, May 3, 2008 9:47:43 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Christoph Kobe
My main question still is: Why is ALT-F4 in the SDL not generating a WM_DESTROY event? With every
other program this is working fine, so there has to be something that prevents the event. I'm not insisting
that this is a bug (although I think so) but I'm asking WHY.
Because SDL hooks the keyboard input at a low enough level that it receives the keypresses before the window manager does. <ALT>-<F4> is defined as a menu shortcut for the Close command in the window's system menu, and then the Close command generates a WM_DESTROY message. But since the window manager never gets the keypress, the shortcut can't be activated. (Opening the system menu with the mouse and selecting Close works just fine.)
Thanks, this is something I was expecting. But since ALT-TAB and CTRL-ALT-DEL still work one could say that this is a flaw in the Windows operating system / window manager. Easy enough to blame Microsoft for this :-)
--
Christoph
from Hamburg, Germany
Mason Wheeler
2008-05-03 18:22:40 UTC
Permalink
----- Original Message ----
From: Christoph Kobe <***@kobenetz.de>
To: ***@libsdl.org
Sent: Saturday, May 3, 2008 11:16:23 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Christoph Kobe
Thanks, this is something I was expecting. But since ALT-TAB and CTRL-ALT-DEL still work one could say
that this is a flaw in the Windows operating system / window manager. Easy enough to blame Microsoft for
this :-)
Now, I'm all for blaming Microsoft for their multitude of screwups, but this is really just a design issue, and it's perfectly consistent behavior. <ALT>-<F4> is supposed to be handled by the application, but <ALT>-<TAB> and <CTRL>-<ALT>-<DEL> are system-level commands that get handled by the OS. If you press those keystrokes, SDL will probably generate the appropriate keypress event, but since the handler's registered at the OS level and not the application level, you don't see any blocking behavior. <ALT>-<F4>, on the other hand, is a menu shortcut that has to be handled by the application.
Christoph Kobe
2008-05-03 18:49:36 UTC
Permalink
On Sat, 3 May 2008 11:22:40 -0700 (PDT)
Post by Mason Wheeler
----- Original Message ----
Sent: Saturday, May 3, 2008 11:16:23 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Christoph Kobe
Thanks, this is something I was expecting. But since ALT-TAB and CTRL-ALT-DEL still work one could say
that this is a flaw in the Windows operating system / window manager. Easy enough to blame Microsoft for
this :-)
Now, I'm all for blaming Microsoft for their multitude of screwups, but this is really just a design issue, and it's perfectly consistent behavior. <ALT>-<F4> is supposed to be handled by the application, but <ALT>-<TAB> and <CTRL>-<ALT>-<DEL> are system-level commands that get handled by the OS. If you press those keystrokes, SDL will probably generate the appropriate keypress event, but since the handler's registered at the OS level and not the application level, you don't see any blocking behavior. <ALT>-<F4>, on the other hand, is a menu shortcut that has to be handled by the application.
Thanks again, I think today I'm learning quiete a lot. I always thought ALT-F4 was handled by the window manager, but apparently this is not true for windows, maybe for KDE. So maybe it would be a solution to remove the ALT-F4 shortcut from the menu entry, because I think nobody will argue that it's a bug in every SDL program when the menu says <close ALT-F4> but ALT-F4 is not working.
--
Christoph
from Hamburg, Germany
Mason Wheeler
2008-05-03 19:04:09 UTC
Permalink
----- Original Message ----
From: Christoph Kobe <***@kobenetz.de>
To: ***@libsdl.org
Sent: Saturday, May 3, 2008 11:49:36 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Christoph Kobe
Thanks again, I think today I'm learning quiete a lot. I always thought ALT-F4 was handled by the
window manager, but apparently this is not true for windows, maybe for KDE. So maybe it would be
a solution to remove the ALT-F4 shortcut from the menu entry, because I think nobody will argue that
it's a bug in every SDL program when the menu says <close ALT-F4> but ALT-F4 is not working.
That would be difficult. The System menu and its contents are provided by the OS as standard features of every ordinary window. I'm not completely certain, but I think that if you wanted to modify it, you'd have to go and design your own window that's identical in every way, except for whatever it was you were modifying.
Erik
2008-05-03 19:58:20 UTC
Permalink
Post by Mason Wheeler
----- Original Message ----
Sent: Saturday, May 3, 2008 11:49:36 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Christoph Kobe
Thanks again, I think today I'm learning quiete a lot. I always thought ALT-F4 was handled by the
window manager, but apparently this is not true for windows, maybe for KDE. So maybe it would be
a solution to remove the ALT-F4 shortcut from the menu entry, because I think nobody will argue that
it's a bug in every SDL program when the menu says <close ALT-F4> but ALT-F4 is not working.
That would be difficult. The System menu and its contents are provided by the OS as standard features of every ordinary window. I'm not completely certain, but I think that if you wanted to modify it, you'd have to go and design your own window that's identical in every way, except for whatever it was you were modifying.
My KDE window manager has a context menu for the window title bar. It
shows a close action and the keyboard shortcut Alt+F4. Someone already
wrote that the KDE window manager catches Alt+F4 and sends a quit event
to the client.

If the MS Windows window manager also shows such a context menu for the
title bar and says that the keyboard shortcut for quit is Alt+F4, it
must also catch Alt+F4 and send to a quit event to the client. Otherwise
the window manager is lying, which is clearly a bug in it. It can not
simply show Alt+F4 in the context menu and hope that the client catches
Alt+F4 and handles it as if it received a quit event from the title bar
context menu, X button or task manager context menu.
Stephen Anthony
2008-05-03 20:09:12 UTC
Permalink
Post by Erik
Post by Mason Wheeler
----- Original Message ----
Sent: Saturday, May 3, 2008 11:49:36 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Christoph Kobe
Thanks again, I think today I'm learning quiete a lot. I always
thought ALT-F4 was handled by the window manager, but apparently
this is not true for windows, maybe for KDE. So maybe it would be
a solution to remove the ALT-F4 shortcut from the menu entry,
because I think nobody will argue that it's a bug in every SDL
program when the menu says <close ALT-F4> but ALT-F4 is not
working.
That would be difficult. The System menu and its contents are
provided by the OS as standard features of every ordinary window.
I'm not completely certain, but I think that if you wanted to
modify it, you'd have to go and design your own window that's
identical in every way, except for whatever it was you were
modifying.
My KDE window manager has a context menu for the window title bar. It
shows a close action and the keyboard shortcut Alt+F4. Someone
already wrote that the KDE window manager catches Alt+F4 and sends a
quit event to the client.
If the MS Windows window manager also shows such a context menu for
the title bar and says that the keyboard shortcut for quit is Alt+F4,
it must also catch Alt+F4 and send to a quit event to the client.
Otherwise the window manager is lying, which is clearly a bug in it.
It can not simply show Alt+F4 in the context menu and hope that the
client catches Alt+F4 and handles it as if it received a quit event
from the title bar context menu, X button or task manager context
menu.
For my two cents worth, this is the most concise (and IMHO correct)
explanation I've seen so far, assuming this is the way it works. If
the WM advertises this functionality, then it's the one responsible for
dealing with it, *not* the application.

If Windows isn't honouring the key-combo, it means the application is
free to catch it (or not). So if the application has a choice, it
isn't a bug in SDL *not* to deal with it; SDL is making a valid choice.

Put another way, if other Windows applications that don't use SDL are
free to ignore Alt-F4, then SDL shouldn't be forced to handle it
either, as it's obviously not a hard requirement to do so.

Steve
Mason Wheeler
2008-05-05 15:57:58 UTC
Permalink
----- Original Message ----
From: Christian Walther <***@gmx.ch>
To: ***@libsdl.org
Sent: Sunday, May 4, 2008 6:19:38 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Christian Walther
That's an idea that has occurred to me as well at one point, in the
context of handling menu keyboard equivalents on Mac OS. My application
is cross-platform for the most part, but has a Mac-specific part that
sets up and handles a Cocoa menu bar. Some menu items in there have
keyboard equivalents, but they don't work unless I check for them
manually in my SDL event handling. It would be nice to have an
SDL_PassEvent() function or something that could be called when the
application wants to pass an event that it doesn't want to handle itself
back to the OS, where, on Mac OS, a key event would eventually be
matched against the menu keyboard equivalents. (I totally agree with
everyone that the application needs to get a chance to process a key
event itself first, before it is eaten up by the keyboard equivalent
handling of the OS (or windowing toolkit or window manager or whatever).)
I have no idea how easy this would be to implement on different
platforms, though.
That's a very interesting idea. I think it would need to be implemented in one of
two ways. Under Windows, events are sent to the application from the OS as
"messages," which SDL intercepts and processes to create SDL events. I
assume a similar system is at work in other OSes. So if you want to pass a
SDL event back to the OS, you either need to extend the SDL event structure
with a pointer back to the original message (which means keeping the message
in memory somewhere until the SDL event that it's connected to has been taken
care of) or implementing a system that will run the process in reverse, creating an
OS message from an SDL event.

Neither of these are particularly efficient. If the only issue is menus, I think a better
solution would be to extend the event system as follows:

1.) Optionally, upon initialization, check to see if the current window has menus. (This
could be skipped under Windows, as every window has a System menu with one
registered keyboard shortcut by default. This may or may not be true under other
OSes.) Also, if it's possible to not have a menu, set up an SDL_EnableMenu() routine
that the app calls when it creates menus.

2.) If menus are currently enabled, when trapping keystrokes, the event system should
automatically run each keypress by the window manager's menu system to see if it's
a valid shortcut, in addition to generating an SDL event. (This is probably the simplest
way to do it. It would be the application programmer's job to make sure that the control
set doesn't overlap with the registered menu shortcuts, to keep the same keypress from
having two effects.)

Good idea? Bad idea? What do you think?
Graham Houston
2008-05-05 16:18:04 UTC
Permalink
Post by Mason Wheeler
----- Original Message ----
Sent: Sunday, May 4, 2008 6:19:38 AM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Christian Walther
That's an idea that has occurred to me as well at one point, in the
context of handling menu keyboard equivalents on Mac OS. My application
is cross-platform for the most part, but has a Mac-specific part that
sets up and handles a Cocoa menu bar. Some menu items in there have
keyboard equivalents, but they don't work unless I check for them
manually in my SDL event handling. It would be nice to have an
SDL_PassEvent() function or something that could be called when the
application wants to pass an event that it doesn't want to handle itself
back to the OS, where, on Mac OS, a key event would eventually be
matched against the menu keyboard equivalents. (I totally agree with
everyone that the application needs to get a chance to process a key
event itself first, before it is eaten up by the keyboard equivalent
handling of the OS (or windowing toolkit or window manager or
whatever).)
I have no idea how easy this would be to implement on different
platforms, though.
That's a very interesting idea. I think it would need to be implemented in one of
two ways. Under Windows, events are sent to the application from the OS as
"messages," which SDL intercepts and processes to create SDL events. I
assume a similar system is at work in other OSes. So if you want to pass a
SDL event back to the OS, you either need to extend the SDL event structure
with a pointer back to the original message (which means keeping the message
in memory somewhere until the SDL event that it's connected to has been taken
care of) or implementing a system that will run the process in reverse, creating an
OS message from an SDL event.
Neither of these are particularly efficient. If the only issue is menus, I think a better
1.) Optionally, upon initialization, check to see if the current window has menus. (This
could be skipped under Windows, as every window has a System menu with one
registered keyboard shortcut by default. This may or may not be true under other
OSes.) Also, if it's possible to not have a menu, set up an
SDL_EnableMenu() routine
that the app calls when it creates menus.
2.) If menus are currently enabled, when trapping keystrokes, the event system should
automatically run each keypress by the window manager's menu system to see if it's
a valid shortcut, in addition to generating an SDL event. (This is probably the simplest
way to do it. It would be the application programmer's job to make sure that the control
set doesn't overlap with the registered menu shortcuts, to keep the same keypress from
having two effects.)
Good idea? Bad idea? What do you think?
I'd like to see this extended a little further to include keys that are
not only menu keys for example ALT+TAB, If I was to develop and I really
am, an enviroment that takes over the entire screen sorta like an OS
inside an OS that creates its own windows etc inside of this SDL
enviroment I still want the interface to be consistant with the OS user
interface.. I want to allow ALT+TAB to switch the windows in my SDL app
etc..

perhaps SDL_disableOSKeys(true|false) ?


Graham.
Post by Mason Wheeler
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Paul Duffy
2008-05-05 16:58:39 UTC
Permalink
Post by Graham Houston
I'd like to see this extended a little further to include keys that are
not only menu keys for example ALT+TAB, If I was to develop and I really
am, an enviroment that takes over the entire screen sorta like an OS
inside an OS that creates its own windows etc inside of this SDL
enviroment I still want the interface to be consistant with the OS user
interface.. I want to allow ALT+TAB to switch the windows in my SDL app
etc..
perhaps SDL_disableOSKeys(true|false) ?
I think something like that would be a solution which would best suit
the majority of people, although to make it more in line with the
majority of APIs (and make it easier to remember) I think enable,
rather than disable, would be the key word. It's clear that some people
want one behaviour while others want the other but the argument that it
should be one to the exclusion of the other is ideological.

1) The argument that not having Alt+F4 is somehow a restriction on the
'freedom of the user' goes directly against the majority exit strategy
of using Esc then selecting from a menu. This is an exit strategy which
has served many large games companies for over a decade and can be seen
in obvious use from Doom to Sims2. Show us the usability study that
demonstrates that using something other than Alt+F4 is some hideous
problem for users/gamers in Windows or drop the attitude. If you want
to make it your way or the highway, you're more than welcome to fork
the project.

2) The other PoV is that having to enable/disable specific keys per O/S
very much defeats the purpose of a cross-platform API, especially if
you're having to do this per function/thread, so having SDL based
commands which will generically enable/disable WM or O/S keys would be
a much more cross-platform way of handling it, especially (as has been
pointed out) you can't even guarantee that close/switch commands will
even be the same between computers running the same versions of Linux
as this is all user configurable.

Realistically, the only solution which is going to work is (as is often
the case) a compromise because:

- Forcing people to accept the O/S key commands without a choice is
stupid.

- Making it difficult (now the problem has been identified) for people
to use the O/S key commands is stupid.

So, being able to identify those key commands (if they are likely to
differ) and choose whether to use them or ignore them should be up to
the individual developer. It may also be necessary to determine which
shell Windows is using, I don't know how configurable LiteStep or
WindowBlinds are.

One thing I will say should never be blockable though, is the
CTRL+ALT+DELETE or equivalent because it's a hubristic developer who
believes his game will never crash (and more often the worst developers
who are guilty of such hubris) and there always needs to be an
'emergency escape'.

"Duct tape is like the Force. It has a dark side, it has a
light side, and it holds the Universe together."
-Carl Zwanig


____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Graham Houston
2008-05-05 17:51:06 UTC
Permalink
Post by Paul Duffy
Post by Graham Houston
I'd like to see this extended a little further to include keys that are
not only menu keys for example ALT+TAB, If I was to develop and I really
am, an enviroment that takes over the entire screen sorta like an OS
inside an OS that creates its own windows etc inside of this SDL
enviroment I still want the interface to be consistant with the OS user
interface.. I want to allow ALT+TAB to switch the windows in my SDL app
etc..
perhaps SDL_disableOSKeys(true|false) ?
I think something like that would be a solution which would best suit
the majority of people, although to make it more in line with the
majority of APIs (and make it easier to remember) I think enable,
rather than disable, would be the key word. It's clear that some people
want one behaviour while others want the other but the argument that it
should be one to the exclusion of the other is ideological.
absolutely...
Post by Paul Duffy
1) The argument that not having Alt+F4 is somehow a restriction on the
'freedom of the user' goes directly against the majority exit strategy
of using Esc then selecting from a menu. This is an exit strategy which
has served many large games companies for over a decade and can be seen
in obvious use from Doom to Sims2. Show us the usability study that
demonstrates that using something other than Alt+F4 is some hideous
problem for users/gamers in Windows or drop the attitude. If you want
to make it your way or the highway, you're more than welcome to fork
the project.
not to mention that not have access to Alt+F4 renders SDL useless for
anything that needs to follow a UI convention inside of SDL, closing UI
windows inside SDL etc..
Post by Paul Duffy
2) The other PoV is that having to enable/disable specific keys per O/S
very much defeats the purpose of a cross-platform API, especially if
you're having to do this per function/thread, so having SDL based
commands which will generically enable/disable WM or O/S keys would be
a much more cross-platform way of handling it, especially (as has been
pointed out) you can't even guarantee that close/switch commands will
even be the same between computers running the same versions of Linux
as this is all user configurable.
Realistically, the only solution which is going to work is (as is often
- Forcing people to accept the O/S key commands without a choice is
stupid.
- Making it difficult (now the problem has been identified) for people
to use the O/S key commands is stupid.
So, being able to identify those key commands (if they are likely to
differ) and choose whether to use them or ignore them should be up to
the individual developer. It may also be necessary to determine which
shell Windows is using, I don't know how configurable LiteStep or
WindowBlinds are.
One thing I will say should never be blockable though, is the
CTRL+ALT+DELETE or equivalent because it's a hubristic developer who
believes his game will never crash (and more often the worst developers
who are guilty of such hubris) and there always needs to be an
'emergency escape'.
"Duct tape is like the Force. It has a dark side, it has a
light side, and it holds the Universe together."
-Carl Zwanig
Yes.. and to reiterate on my own dilemma people use SDL for more than game
development and some things that people develop need these OS keys
to function as they would not on the overall OS but inside the SDL app
that's running.


Graham
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Erik
2008-05-05 18:39:22 UTC
Permalink
You can't usefully block control-alt-delete on Windows, so that's not a
problem. Incidentally, I believe that alt-f4, control-alt-delete and
alt-tab, by virtue of being Windows application/window management functions,
should (in the vast majority of cases) sacrosanct because they should be
available even if you don't know anything about the game, on anybody's
Windows machine. If you change those, anybody not familiar with your
application is going to be screwed. In effect your game is changing the
rules of the OS, which is not acceptable IMO. unless we are talking
emulators, most applications are not little worlds unto themselves. They are
apps on a platform and they should obey the platform convention to a at
least the minimal extent that you can close or navigate away from the app.
Not making that the default behavior encourages abuse IMO.

Erik
Post by Paul Duffy
Post by Graham Houston
I'd like to see this extended a little further to include keys that are
not only menu keys for example ALT+TAB, If I was to develop and I really
am, an enviroment that takes over the entire screen sorta like an OS
inside an OS that creates its own windows etc inside of this SDL
enviroment I still want the interface to be consistant with the OS user
interface.. I want to allow ALT+TAB to switch the windows in my SDL app
etc..
perhaps SDL_disableOSKeys(true|false) ?
I think something like that would be a solution which would best suit
the majority of people, although to make it more in line with the
majority of APIs (and make it easier to remember) I think enable,
rather than disable, would be the key word. It's clear that some people
want one behaviour while others want the other but the argument that it
should be one to the exclusion of the other is ideological.
1) The argument that not having Alt+F4 is somehow a restriction on the
'freedom of the user' goes directly against the majority exit strategy
of using Esc then selecting from a menu. This is an exit strategy which
has served many large games companies for over a decade and can be seen
in obvious use from Doom to Sims2. Show us the usability study that
demonstrates that using something other than Alt+F4 is some hideous
problem for users/gamers in Windows or drop the attitude. If you want
to make it your way or the highway, you're more than welcome to fork
the project.
2) The other PoV is that having to enable/disable specific keys per O/S
very much defeats the purpose of a cross-platform API, especially if
you're having to do this per function/thread, so having SDL based
commands which will generically enable/disable WM or O/S keys would be
a much more cross-platform way of handling it, especially (as has been
pointed out) you can't even guarantee that close/switch commands will
even be the same between computers running the same versions of Linux
as this is all user configurable.
Realistically, the only solution which is going to work is (as is often
- Forcing people to accept the O/S key commands without a choice is
stupid.
- Making it difficult (now the problem has been identified) for people
to use the O/S key commands is stupid.
So, being able to identify those key commands (if they are likely to
differ) and choose whether to use them or ignore them should be up to
the individual developer. It may also be necessary to determine which
shell Windows is using, I don't know how configurable LiteStep or
WindowBlinds are.
One thing I will say should never be blockable though, is the
CTRL+ALT+DELETE or equivalent because it's a hubristic developer who
believes his game will never crash (and more often the worst developers
who are guilty of such hubris) and there always needs to be an
'emergency escape'.
"Duct tape is like the Force. It has a dark side, it has a
light side, and it holds the Universe together."
-Carl Zwanig
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Aide-toi, le Ciel t'aidera
Graham Houston
2008-05-05 19:03:07 UTC
Permalink
Post by Erik
You can't usefully block control-alt-delete on Windows, so that's not a
problem. Incidentally, I believe that alt-f4, control-alt-delete and
alt-tab, by virtue of being Windows application/window management functions,
should (in the vast majority of cases) sacrosanct because they should be
available even if you don't know anything about the game, on anybody's
Windows machine. If you change those, anybody not familiar with your
application is going to be screwed. In effect your game is changing the
rules of the OS, which is not acceptable IMO. unless we are talking
emulators, most applications are not little worlds unto themselves. They are
apps on a platform and they should obey the platform convention to a at
least the minimal extent that you can close or navigate away from the app.
Not making that the default behavior encourages abuse IMO.
"in the vast majority of cases" being the key here! but as you said
yourself "emulators" or system apps that are intended to be the only thing
running on the OS's Window Manager.. for example full screen apps that IMO
are no longer window apps rather something that is utilizing the OS as a
whole to do something specific. What's the harm with giving more overall
control to the developer if that's what they need.

Again I bring up the UI interface inside an SDL application, how can the
SDL UI function as people expect it to if the key combo's it relies on are
being used by the OS under the app. I have a window running inside my
fullscreen SDL app I want ALT+F4 to close this window not the window the
app is running inside and I also want ALT+TAB to switch windows in my app
not the apps running on the OS.


Graham
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Erik
2008-05-05 19:28:18 UTC
Permalink
It's not conceited or arrogant, it's just true. If you don't make sensible
defaults, people will design whatever they want and most people don't read
the HIG and/or their project manager doesn't care. Another self-evident fact
I'm going to assert is that games are way behind other categories of apps in
providing a consistent, non-messy interface, so to say that everyone (at
least in the games world) has done it this way for years is not really a
defense of what ought to be done. I'm not arguing against giving app
developers that control, I'm trying to make the case for "sensible" defaults
so that by default the application developer doesn't have to address what
normal OS keypresses switch apps or close the app. If you want to make the
game exit on a menu from an ESC keypress, well I'm not arguing that games
shouldn't have an exit option on the menu.

Erik

On Mon, May 5, 2008 at 2:03 PM, Graham Houston <
Post by Erik
You can't usefully block control-alt-delete on Windows, so that's not a
Post by Erik
problem. Incidentally, I believe that alt-f4, control-alt-delete and
alt-tab, by virtue of being Windows application/window management functions,
should (in the vast majority of cases) sacrosanct because they should be
available even if you don't know anything about the game, on anybody's
Windows machine. If you change those, anybody not familiar with your
application is going to be screwed. In effect your game is changing the
rules of the OS, which is not acceptable IMO. unless we are talking
emulators, most applications are not little worlds unto themselves. They are
apps on a platform and they should obey the platform convention to a at
least the minimal extent that you can close or navigate away from the app.
Not making that the default behavior encourages abuse IMO.
"in the vast majority of cases" being the key here! but as you said
yourself "emulators" or system apps that are intended to be the only thing
running on the OS's Window Manager.. for example full screen apps that IMO
are no longer window apps rather something that is utilizing the OS as a
whole to do something specific. What's the harm with giving more overall
control to the developer if that's what they need.
Again I bring up the UI interface inside an SDL application, how can the
SDL UI function as people expect it to if the key combo's it relies on are
being used by the OS under the app. I have a window running inside my
fullscreen SDL app I want ALT+F4 to close this window not the window the app
is running inside and I also want ALT+TAB to switch windows in my app not
the apps running on the OS.
Graham
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Aide-toi, le Ciel t'aidera
Paul Duffy
2008-05-05 19:08:22 UTC
Permalink
Post by Erik
You can't usefully block control-alt-delete on Windows, so that's not a
problem. Incidentally, I believe that alt-f4, control-alt-delete and
alt-tab, by virtue of being Windows application/window management functions,
should (in the vast majority of cases) sacrosanct because they should be
available even if you don't know anything about the game, on
anybody's
Windows machine. If you change those, anybody not familiar with your
application is going to be screwed. In effect your game is changing the
rules of the OS, which is not acceptable IMO. unless we are talking
emulators, most applications are not little worlds unto themselves. They are
apps on a platform and they should obey the platform convention to a at
least the minimal extent that you can close or navigate away from the app.
Not making that the default behavior encourages abuse IMO.
Well, someone needs to tell EA, Blizzard, Lucasartsm ID and all the
others to stop doing things the way they're doing them because
apparently blocking Alt+F4 is a major problem, only no-one's told them
about it in over 10 years. Since before the GUI was actually part of
the Microsoft O/S, and not just running on top of it, the convention
has been to use Esc to bring up a menu to quit and it's something few,
if any, people don't understand so trying to force something that is a
matter of opinion on people by claiming that it 'encourages abuse'
(with exactly zero evidence to back this up) is conceited and arrogant.

Unless you can pull up some figures demonstrating that this actually
causes a problem, there is absolutely no reason to enforce this as a
requirement. I agree it should be available should the _developer_
require it. Enforcing it as a mandatory requirement, however, is just
forcing something as insubstantial as a subjective opinion on other
people.

I don't even care if you're referring to those irritating cutscenes
which block all control and which you have to sit through whether you
like it or not because there is no reason why they couldn't block a
quit request (and it is a request) just the same way whether it's
through Esc or Alt+F4 e.g

int quit( pointers for data freeing )
{

}

--

"Duct tape is like the Force. It has a dark side, it has a
light side, and it holds the Universe together."
-Carl Zwanig


____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Charles McGarvey
2008-05-05 19:23:06 UTC
Permalink
I don't know about the others, but I'm pretty sure Blizzard does make ALT-F4
exit the application (at least in WC3). If you're in a game, it will ask
you if you really want to quit, otherwise it will just quit (as most people
would expect). This seems like the best solution; better than pressing
<esc> and hoping you don't have to search through menus to make the app
quit. From the full-screen games I've played, ALT-F4 is every bit a
"convention" as <esc> is, ALT-F4 being the "exit immediately, no foolin'"
method.

Most people will want ALT-F4 to exactly represent closing a window (or
exiting the app if full-screen), so it make sense to correlate it with the
'quit' event as the _default_ (but overridable) behavior. IMO.

chaz

----- Original Message -----
From: "Paul Duffy" <***@yahoo.co.uk>
To: "A list for developers using the SDL library. (includes SDL-announce)"
<***@lists.libsdl.org>
Sent: Monday, May 05, 2008 1:08 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Paul Duffy
Post by Erik
You can't usefully block control-alt-delete on Windows, so that's not a
problem. Incidentally, I believe that alt-f4, control-alt-delete and
alt-tab, by virtue of being Windows application/window management functions,
should (in the vast majority of cases) sacrosanct because they should be
available even if you don't know anything about the game, on
anybody's
Windows machine. If you change those, anybody not familiar with your
application is going to be screwed. In effect your game is changing the
rules of the OS, which is not acceptable IMO. unless we are talking
emulators, most applications are not little worlds unto themselves. They are
apps on a platform and they should obey the platform convention to a at
least the minimal extent that you can close or navigate away from the app.
Not making that the default behavior encourages abuse IMO.
Well, someone needs to tell EA, Blizzard, Lucasartsm ID and all the
others to stop doing things the way they're doing them because
apparently blocking Alt+F4 is a major problem, only no-one's told them
about it in over 10 years. Since before the GUI was actually part of
the Microsoft O/S, and not just running on top of it, the convention
has been to use Esc to bring up a menu to quit and it's something few,
if any, people don't understand so trying to force something that is a
matter of opinion on people by claiming that it 'encourages abuse'
(with exactly zero evidence to back this up) is conceited and arrogant.
Unless you can pull up some figures demonstrating that this actually
causes a problem, there is absolutely no reason to enforce this as a
requirement. I agree it should be available should the _developer_
require it. Enforcing it as a mandatory requirement, however, is just
forcing something as insubstantial as a subjective opinion on other
people.
I don't even care if you're referring to those irritating cutscenes
which block all control and which you have to sit through whether you
like it or not because there is no reason why they couldn't block a
quit request (and it is a request) just the same way whether it's
through Esc or Alt+F4 e.g
int quit( pointers for data freeing )
{
}
--
"Duct tape is like the Force. It has a dark side, it has a
light side, and it holds the Universe together."
-Carl Zwanig
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Graham Houston
2008-05-05 19:34:59 UTC
Permalink
On Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey
Post by Charles McGarvey
I don't know about the others, but I'm pretty sure Blizzard does make
ALT-F4 exit the application (at least in WC3). If you're in a game, it
will ask you if you really want to quit,
So whatever they use doe's not do the default on ALT+F4 it's hooked so
they can give an option! that's the point we're making, how do we get this
control in SDL if it's buried in a way that we have no control over it.



otherwise it will just quit (as
Post by Charles McGarvey
most people would expect). This seems like the best solution; better
than pressing <esc> and hoping you don't have to search through menus to
make the app quit. From the full-screen games I've played, ALT-F4 is
every bit a "convention" as <esc> is, ALT-F4 being the "exit
immediately, no foolin'" method.
Most people will want ALT-F4 to exactly represent closing a window (or
exiting the app if full-screen), so it make sense to correlate it with
the 'quit' event as the _default_ (but overridable) behavior. IMO.
chaz
To: "A list for developers using the SDL library. (includes
Sent: Monday, May 05, 2008 1:08 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Paul Duffy
Post by Erik
You can't usefully block control-alt-delete on Windows, so that's not a
problem. Incidentally, I believe that alt-f4, control-alt-delete and
alt-tab, by virtue of being Windows application/window management functions,
should (in the vast majority of cases) sacrosanct because they should be
available even if you don't know anything about the game, on
anybody's
Windows machine. If you change those, anybody not familiar with your
application is going to be screwed. In effect your game is changing the
rules of the OS, which is not acceptable IMO. unless we are talking
emulators, most applications are not little worlds unto themselves. They are
apps on a platform and they should obey the platform convention to a at
least the minimal extent that you can close or navigate away from the app.
Not making that the default behavior encourages abuse IMO.
Well, someone needs to tell EA, Blizzard, Lucasartsm ID and all the
others to stop doing things the way they're doing them because
apparently blocking Alt+F4 is a major problem, only no-one's told them
about it in over 10 years. Since before the GUI was actually part of
the Microsoft O/S, and not just running on top of it, the convention
has been to use Esc to bring up a menu to quit and it's something few,
if any, people don't understand so trying to force something that is a
matter of opinion on people by claiming that it 'encourages abuse'
(with exactly zero evidence to back this up) is conceited and arrogant.
Unless you can pull up some figures demonstrating that this actually
causes a problem, there is absolutely no reason to enforce this as a
requirement. I agree it should be available should the _developer_
require it. Enforcing it as a mandatory requirement, however, is just
forcing something as insubstantial as a subjective opinion on other
people.
I don't even care if you're referring to those irritating cutscenes
which block all control and which you have to sit through whether you
like it or not because there is no reason why they couldn't block a
quit request (and it is a request) just the same way whether it's
through Esc or Alt+F4 e.g
int quit( pointers for data freeing )
{
}
--
"Duct tape is like the Force. It has a dark side, it has a
light side, and it holds the Universe together."
-Carl Zwanig
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Erik
2008-05-05 19:43:38 UTC
Permalink
Unless I missed something in a prior mail, all we are talking about here is
whether or not SDL will honor Windows sending an alt-f4 as a WM_QUIT event
(that you still have to handle yourself in your code) or instead send it as
an alt-f4 keypress event to give the programmer maximum flexibility. Not
exit without program intervention or anything like that.

Erik

On Mon, May 5, 2008 at 2:34 PM, Graham Houston <
On Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey <
I don't know about the others, but I'm pretty sure Blizzard does make
ALT-F4 exit the application (at least in WC3). If you're in a game, it will
ask you if you really want to quit,
So whatever they use doe's not do the default on ALT+F4 it's hooked so
they can give an option! that's the point we're making, how do we get this
control in SDL if it's buried in a way that we have no control over it.
otherwise it will just quit (as
most people would expect). This seems like the best solution; better
than pressing <esc> and hoping you don't have to search through menus to
make the app quit. From the full-screen games I've played, ALT-F4 is every
bit a "convention" as <esc> is, ALT-F4 being the "exit immediately, no
foolin'" method.
Most people will want ALT-F4 to exactly represent closing a window (or
exiting the app if full-screen), so it make sense to correlate it with the
'quit' event as the _default_ (but overridable) behavior. IMO.
chaz
To: "A list for developers using the SDL library. (includes
Sent: Monday, May 05, 2008 1:08 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Erik
You can't usefully block control-alt-delete on Windows, so that's not
Post by Erik
a
problem. Incidentally, I believe that alt-f4, control-alt-delete and
alt-tab, by virtue of being Windows application/window management functions,
should (in the vast majority of cases) sacrosanct because they
should
be
available even if you don't know anything about the game, on
anybody's
Windows machine. If you change those, anybody not familiar with your
application is going to be screwed. In effect your game is changing the
rules of the OS, which is not acceptable IMO. unless we are talking
emulators, most applications are not little worlds unto themselves. They are
apps on a platform and they should obey the platform convention to a at
least the minimal extent that you can close or navigate away from
the
app.
Not making that the default behavior encourages abuse IMO.
Well, someone needs to tell EA, Blizzard, Lucasartsm ID and all the
others to stop doing things the way they're doing them because
apparently blocking Alt+F4 is a major problem, only no-one's told them
about it in over 10 years. Since before the GUI was actually part of
the Microsoft O/S, and not just running on top of it, the convention
has been to use Esc to bring up a menu to quit and it's something few,
if any, people don't understand so trying to force something that is a
matter of opinion on people by claiming that it 'encourages abuse'
(with exactly zero evidence to back this up) is conceited and arrogant.
Unless you can pull up some figures demonstrating that this actually
causes a problem, there is absolutely no reason to enforce this as a
requirement. I agree it should be available should the _developer_
require it. Enforcing it as a mandatory requirement, however, is just
forcing something as insubstantial as a subjective opinion on other
people.
I don't even care if you're referring to those irritating cutscenes
which block all control and which you have to sit through whether you
like it or not because there is no reason why they couldn't block a
quit request (and it is a request) just the same way whether it's
through Esc or Alt+F4 e.g
int quit( pointers for data freeing )
{
}
--
"Duct tape is like the Force. It has a dark side, it has a
light side, and it holds the Universe together."
-Carl Zwanig
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Aide-toi, le Ciel t'aidera
Graham Houston
2008-05-05 19:48:14 UTC
Permalink
Post by Erik
Unless I missed something in a prior mail, all we are talking about here is
whether or not SDL will honor Windows sending an alt-f4 as a WM_QUIT event
(that you still have to handle yourself in your code) or instead send it as
an alt-f4 keypress event to give the programmer maximum flexibility. Not
exit without program intervention or anything like that.
Well Sam has already pointed out that this is a bug and will be fixed in
the next update.. So other people are still arguing that we need some way
to control OS keys...

The issue is not UI ethics it's SDL not having the ability to control OS
keys.


Graham
Post by Erik
Erik
On Mon, May 5, 2008 at 2:34 PM, Graham Houston <
On Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey <
I don't know about the others, but I'm pretty sure Blizzard does make
Post by Charles McGarvey
ALT-F4 exit the application (at least in WC3). If you're in a game,
it will
Post by Charles McGarvey
ask you if you really want to quit,
So whatever they use doe's not do the default on ALT+F4 it's hooked so
they can give an option! that's the point we're making, how do we get this
control in SDL if it's buried in a way that we have no control over it.
otherwise it will just quit (as
Post by Charles McGarvey
most people would expect). This seems like the best solution; better
than pressing <esc> and hoping you don't have to search through menus
to
Post by Charles McGarvey
make the app quit. From the full-screen games I've played, ALT-F4 is
every
Post by Charles McGarvey
bit a "convention" as <esc> is, ALT-F4 being the "exit immediately, no
foolin'" method.
Most people will want ALT-F4 to exactly represent closing a window (or
exiting the app if full-screen), so it make sense to correlate it
with the
Post by Charles McGarvey
'quit' event as the _default_ (but overridable) behavior. IMO.
chaz
To: "A list for developers using the SDL library. (includes
Sent: Monday, May 05, 2008 1:08 PM
Subject: Re: [SDL] Alt-F4 not working on Windows
Post by Erik
You can't usefully block control-alt-delete on Windows, so that's
not
Post by Charles McGarvey
Post by Erik
Post by Erik
a
problem. Incidentally, I believe that alt-f4, control-alt-delete
and
Post by Charles McGarvey
Post by Erik
Post by Erik
alt-tab, by virtue of being Windows application/window management functions,
should (in the vast majority of cases) sacrosanct because they
should
be
available even if you don't know anything about the game, on
anybody's
Windows machine. If you change those, anybody not familiar with
your
Post by Charles McGarvey
Post by Erik
Post by Erik
application is going to be screwed. In effect your game is
changing
Post by Charles McGarvey
Post by Erik
Post by Erik
the
rules of the OS, which is not acceptable IMO. unless we are
talking
Post by Charles McGarvey
Post by Erik
Post by Erik
emulators, most applications are not little worlds unto
themselves.
Post by Charles McGarvey
Post by Erik
Post by Erik
They are
apps on a platform and they should obey the platform convention
to a
Post by Charles McGarvey
Post by Erik
Post by Erik
at
least the minimal extent that you can close or navigate away from
the
app.
Not making that the default behavior encourages abuse IMO.
Well, someone needs to tell EA, Blizzard, Lucasartsm ID and all the
others to stop doing things the way they're doing them because
apparently blocking Alt+F4 is a major problem, only no-one's told
them
Post by Charles McGarvey
Post by Erik
about it in over 10 years. Since before the GUI was actually part of
the Microsoft O/S, and not just running on top of it, the convention
has been to use Esc to bring up a menu to quit and it's something
few,
Post by Charles McGarvey
Post by Erik
if any, people don't understand so trying to force something that
is a
Post by Charles McGarvey
Post by Erik
matter of opinion on people by claiming that it 'encourages abuse'
(with exactly zero evidence to back this up) is conceited and arrogant.
Unless you can pull up some figures demonstrating that this actually
causes a problem, there is absolutely no reason to enforce this as a
requirement. I agree it should be available should the _developer_
require it. Enforcing it as a mandatory requirement, however, is
just
Post by Charles McGarvey
Post by Erik
forcing something as insubstantial as a subjective opinion on other
people.
I don't even care if you're referring to those irritating cutscenes
which block all control and which you have to sit through whether
you
Post by Charles McGarvey
Post by Erik
like it or not because there is no reason why they couldn't block a
quit request (and it is a request) just the same way whether it's
through Esc or Alt+F4 e.g
int quit( pointers for data freeing )
{
}
--
"Duct tape is like the Force. It has a dark side, it has a
light side, and it holds the Universe together."
-Carl Zwanig
____________________________________________________________________________________
Post by Charles McGarvey
Post by Erik
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Charles McGarvey
2008-05-06 00:30:35 UTC
Permalink
Let me be more clear. You could implement this behavior more easily if SDL *was* hooked to generate a 'quit' event for ALT-F4. The behavior of WC3 confirming the quit or not should be implemented in the 'quit' event handler itself, not by catching any key sequences. For example, if WC3 ran in a window rather than full-screen, you would want the exact same behavior if the user clicked on the 'close' widget of the window.

This is expected behavior, and while I won't go as far as to claim its a right of the user, as some have already, I will argue that equating ALT-F4 with the 'quit' event makes sense as the default behavior since it is the desired behavior in most cases. Also, like I said previously, it ought to be overridable so that people who need to catch special key sequences can do so.

I'm not talking about the program exiting without program intervention which, I believe, is a point that you brought up awhile ago that really has nothing to do with this discussion. Hopefully the point I made is clearer now. I've been following this thread somewhat casually, so if this point has already been established and the discussion has turned to the technical matters of implementation or something else, then I am sorry; move along.

chaz
----- Original Message -----
From: Erik
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Monday, May 05, 2008 1:43 PM
Subject: Re: [SDL] Alt-F4 not working on Windows


Unless I missed something in a prior mail, all we are talking about here is whether or not SDL will honor Windows sending an alt-f4 as a WM_QUIT event (that you still have to handle yourself in your code) or instead send it as an alt-f4 keypress event to give the programmer maximum flexibility. Not exit without program intervention or anything like that.

Erik


On Mon, May 5, 2008 at 2:34 PM, Graham Houston <***@rushpark.co.uk> wrote:

On Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey <***@brokenzipper.com> wrote:


I don't know about the others, but I'm pretty sure Blizzard does make ALT-F4 exit the application (at least in WC3). If you're in a game, it will ask you if you really want to quit,



So whatever they use doe's not do the default on ALT+F4 it's hooked so they can give an option! that's the point we're making, how do we get this control in SDL if it's buried in a way that we have no control over it.
Erik
2008-05-06 02:20:11 UTC
Permalink
I didn't say that. I was addressing the prior statement because I didn't
understand at all how a game giving an option on alt-f4 (instead of just
exiting) means that the OS (programmatic) default behavior is being
overridden somehow. It's just handling the QUIT event instead of ALT-F4
keypress event. That's also what you just said, right? it's not like QUIT
event blows a hole in your program to escape, that's just how some people
implement it rather than give you a warning like choosing quit from a menu
might. My position from the beginning was that it should be possible to
override behavior of things like alt-f4 or alt-tab on Windows, but I had
also stated tangentially that most apps really shouldn't. So anyway, back to
the topic at hand.

Erik

On Mon, May 5, 2008 at 7:30 PM, Charles McGarvey <
Post by Charles McGarvey
I'm not talking about the program exiting without program intervention
which, I believe, is a point that you brought up awhile ago that really has
nothing to do with this discussion. Hopefully the point I made is clearer
now. I've been following this thread somewhat casually, so if this point
has already been established and the discussion has turned to the technical
matters of implementation or something else, then I am sorry; move along.
chaz
----- Original Message -----
*Sent:* Monday, May 05, 2008 1:43 PM
*Subject:* Re: [SDL] Alt-F4 not working on Windows
Unless I missed something in a prior mail, all we are talking about here
is whether or not SDL will honor Windows sending an alt-f4 as a WM_QUIT
event (that you still have to handle yourself in your code) or instead send
it as an alt-f4 keypress event to give the programmer maximum flexibility.
Not exit without program intervention or anything like that.
Erik
On Mon, May 5, 2008 at 2:34 PM, Graham Houston <
On Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey <
I don't know about the others, but I'm pretty sure Blizzard does make
ALT-F4 exit the application (at least in WC3). If you're in a game, it will
ask you if you really want to quit,
So whatever they use doe's not do the default on ALT+F4 it's hooked so
they can give an option! that's the point we're making, how do we get this
control in SDL if it's buried in a way that we have no control over it.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Aide-toi, le Ciel t'aidera
Graham Houston
2008-05-05 19:45:46 UTC
Permalink
On Mon, 05 May 2008 20:34:59 +0100, Graham Houston
<***@rushpark.co.uk> wrote:


Here's an idea!

what if you could send an SDL event that tells SDL to turn on or off its
default behaviour for OS keys, something in the SDL_SysWMEvent perhaps..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Paul Duffy
2008-05-05 19:12:54 UTC
Permalink
Try that again (stupid IE7)
Post by Erik
You can't usefully block control-alt-delete on Windows, so that's not a
problem. Incidentally, I believe that alt-f4, control-alt-delete and
alt-tab, by virtue of being Windows application/window management functions,
should (in the vast majority of cases) sacrosanct because they should be
available even if you don't know anything about the game, on
anybody's
Windows machine. If you change those, anybody not familiar with your
application is going to be screwed. In effect your game is changing the
rules of the OS, which is not acceptable IMO. unless we are talking
emulators, most applications are not little worlds unto themselves. They are
apps on a platform and they should obey the platform convention to a at
least the minimal extent that you can close or navigate away from the app.
Not making that the default behavior encourages abuse IMO.
Well, someone needs to tell EA, Blizzard, Lucasarts, ID and all the
others to stop doing things the way they're doing them because
apparently blocking Alt+F4 is a major problem, only no-one's told them
about it in over 10 years. Since before the GUI was actually part of
the Microsoft O/S, and not just running on top of it, the convention
has been to use Esc to bring up a menu to quit and it's something few,
if any, people don't understand so trying to force something that is a
matter of opinion on people by claiming that it 'encourages abuse'
(with exactly zero evidence to back this up) is conceited and arrogant.

Unless you can pull up some figures demonstrating that this actually
causes a problem, there is absolutely no reason to enforce this as a
requirement. I agree it should be available should the _developer_
require it. Enforcing it as a mandatory requirement, however, is just
forcing something as insubstantial as a subjective opinion on other
people.

I don't even care if you're referring to those irritating cutscenes
which block all control and which you have to sit through whether you
like it or not because there is no reason why they couldn't block a
quit request (and it is a request) just the same way whether it's
through Esc or Alt+F4 e.g

int quit( pointers for data freeing )
{
if (canstop = 0)
tell user to suck on it
}

Games have rarely, if ever, stuck to Windows, OSX or any other
conventions for what particular keypresses do so expecting to be able
to enforce anything else on developers without anyone else having a say
is ludicrous.

--

"Duct tape is like the Force. It has a dark side, it has a
light side, and it holds the Universe together."
-Carl Zwanig


____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Continue reading on narkive:
Loading...