Alt-F4 not working on Windows

SDL Development
81

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?

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.On Mon, 05 May 2008 16:57:58 +0100, Mason Wheeler wrote:

----- Original Message ----
From: Christian Walther
To: sdl at libsdl.org
Sent: Sunday, May 4, 2008 6:19:38 AM
Subject: Re: [SDL] Alt-F4 not working on Windows

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

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

82

— Graham Houston <graham.houston at rushpark.co.uk> wrote:

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. Home | Yahoo Mobile

83

— Graham Houston <@Graham_Houston> wrote:

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…

  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…

  1. 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

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.

GrahamOn Mon, 05 May 2008 17:58:39 +0100, Paul Duffy wrote:

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

84

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.

ErikOn Mon, May 5, 2008 at 11:58 AM, Paul Duffy wrote:

— Graham Houston <graham.houston at rushpark.co.uk> wrote:

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.
Home | Yahoo Mobile

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

–
Aide-toi, le Ciel t’aidera

85

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.

GrahamOn Mon, 05 May 2008 19:39:22 +0100, Erik <libsdl.org at mail.obsequious.org> wrote:

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

86

— Erik <libsdl.org at mail.obsequious.org> wrote:

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. Home | Yahoo Mobile

87

Try that again (stupid IE7)

— Erik <libsdl.org at mail.obsequious.org> wrote:

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. Home | Yahoo Mobile

88

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
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 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: odubtaig@yahoo.co.uk (Paul Duffy)
To: “A list for developers using the SDL library. (includes SDL-announce)”

Sent: Monday, May 05, 2008 1:08 PM
Subject: Re: [SDL] Alt-F4 not working on Windows

— Erik <libsdl.org at mail.obsequious.org> wrote:

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.
Home | Yahoo Mobile

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

89

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.

ErikOn Mon, May 5, 2008 at 2:03 PM, Graham Houston < graham.houston at rushpark.co.uk> wrote:

On Mon, 05 May 2008 19:39:22 +0100, Erik <@Erik2> wrote:

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: Opera Web Browser | Faster, Safer, Smarter | Opera

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

–
Aide-toi, le Ciel t’aidera

90

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 (asOn Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey wrote:

most people would expect). This seems like the best solution; better
than pressing 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 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”
To: “A list for developers using the SDL library. (includes
SDL-announce)”
Sent: Monday, May 05, 2008 1:08 PM
Subject: Re: [SDL] Alt-F4 not working on Windows

— Erik <libsdl.org at mail.obsequious.org> wrote:

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.
Home | Yahoo Mobile

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

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

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

91

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.

ErikOn Mon, May 5, 2008 at 2:34 PM, Graham Houston < graham.houston at rushpark.co.uk> wrote:

On Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey < onefriedrice at 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.

otherwise it will just quit (as

most people would expect). This seems like the best solution; better
than pressing 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 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”
To: “A list for developers using the SDL library. (includes
SDL-announce)”
Sent: Monday, May 05, 2008 1:08 PM
Subject: Re: [SDL] Alt-F4 not working on Windows

— Erik <@Erik2> wrote:

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.
Home | Yahoo Mobile

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

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

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

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

–
Aide-toi, le Ciel t’aidera

92

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…On Mon, 05 May 2008 20:34:59 +0100, Graham Houston <@Graham_Houston> wrote:

–
Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/

93

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.

GrahamOn Mon, 05 May 2008 20:43:38 +0100, Erik <libsdl.org at mail.obsequious.org> wrote:

Erik

On Mon, May 5, 2008 at 2:34 PM, Graham Houston < @Graham_Houston> wrote:

On Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey < onefriedrice at 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.

otherwise it will just quit (as

most people would expect). This seems like the best solution; better
than pressing 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 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”
To: “A list for developers using the SDL library. (includes
SDL-announce)”
Sent: Monday, May 05, 2008 1:08 PM
Subject: Re: [SDL] Alt-F4 not working on Windows

— Erik <libsdl.org at mail.obsequious.org> wrote:

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.
Home | Yahoo Mobile

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

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

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

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

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

94

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 <graham.houston at rushpark.co.uk> wrote:

On Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey <@Charles_McGarvey> 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.
95

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.

ErikOn Mon, May 5, 2008 at 7:30 PM, Charles McGarvey < onefriedrice at brokenzipper.com> wrote:

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 <@Erik2>
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 < graham.houston at rushpark.co.uk> wrote:

On Mon, 05 May 2008 20:23:06 +0100, Charles McGarvey < onefriedrice at 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.

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

–
Aide-toi, le Ciel t’aidera