Should SDL2 handle standard keyboard shortcuts?

SDL Development
21

yes, this is the code maker job. He is the decider. A cross platform lib
lrts me make one app that does the same thing on all os. i do this. When i
am in the os making changes it’s crazy to plan for the quit so i check but
don’t do anything unless im not busy. Even microsost os will be destroyed
if its stopped when doing an update. the key press are there to check which
is easy and i dont worry about alternate methods and what they mean unless
all are the same. I have to write the same ammount of code to handle sdl if
its included and if its not. it’s about 1 line of code no matter what the
caes.On Thu, Jul 26, 2012 at 7:28 PM, Daniel Leslie wrote:

What about providing a way of determining if a given chord is a system
interaction and what the probable intent is, but stop short of actually
following through with the intent?

-Dan
On Jul 26, 2012 4:04 PM, “Gabriel Jacobo” wrote:

I asked Sam why SDL2 is not generating a WM_CLOSE when the user presses
ALT+F4 under Windows, and he told me that by design SDL lets the user
handle all combinations of key presses, though this forces the developer to
write some platform dependent code to catch those events (ALT+F4 on
Windows, CMD+Q on OS X…etc?). He said he is on the fence on this issue
and to propose a poll on the list, so here it is…the “Grand 2012 Keyboard
System Shortcuts Poll”.

I’ll start with my vote, I’m 51% in favor of handling these combos
internally.

–
Gabriel.

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

22

My understanding (having written Win32 code before) is that the event handler must return a bool status to indicate whether the event should be passed on to the system for handling, the common
behavior is to pass on all events after handling them - with some exceptions (like if you want to suppress screensavers you can intentionally not accept the screensaver event).

My expectation of SDL2 is that it will pass along all events that it has not been hinted by the app should be suppressed, so for example alt-f4 requires no special handling in SDL2 or the app as long
as it passes on keyboard events, which will in turn produce a WM_CLOSE event that will be delivered by SDL2 to the app to react to.On 07/27/2012 08:14 AM, Mason Wheeler wrote:

You’re missing the point. ALT-F4 shouldn’t be an automatic quit, and no one is saying that it should. But it absolutely should send the quit signal to the program, to be handled appropriately,
whether by quitting or by asking the user if they really want to quit. But right now SDL does not do that, and in fact it gets in the way. That needs to change.

From: R Manard
To: SDL Development List
Sent: Friday, July 27, 2012 7:20 AM
Subject: Re: [SDL] Should SDL2 handle standard keyboard shortcuts?

In windows microsoft wants the user to handle it if they want alt and f4 to close thte window. You are checking for input anyway. THe reason it’s gone this long without gettting done is that if you
want it you just add one line of code (maybe two or three if you break it up):

case SDLK_F4:
if(ev->key.keysym.sym == SDLK_RALT) {do_something_first(); SDL_Quit;}
if(ev->key.keysym.sym == SDLK_LALT) {do_something_first(); SDL_Quit;}

so now you have a cross platform way to check and do it. Lib seems like a lot of effort for that to do that to me. The first time i pressed alt and f4 to check if sdl made it quit I was relieved that
it did not default to this because it is not a default behavior of windows. Each application decides to handle or not to handle it. Most of my games do the above but some dont because I want to ask
them if that’s what they really want first. Online people trick each other by saying “ohh x, you can fix x by pressing alt and f4” to trick them into exiting the game on accident. If i was doing a
system changes it would be bad to abort it also before it completes too. The alternate code if it was in sdl would look something like this i think:

case SDL_ALT_N_F4:
do_it = check_if_user_wants_quit();
if(do_it) {do_something_first(); SDL_Quit;}

Could be plenty ways to do it I’m not thinking of. For me the sdl include of this would not help me. I guess thats all i had to say.

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

SDL mailing list
SDL at lists.libsdl.org <mailto: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

–
LordHavoc
Author of DarkPlaces Quake1 engine - LadyHavoc's DarkPlaces Quake Modification
Co-designer of Nexuiz - Nexuiz Classic – Alientrap
“War does not prove who is right, it proves who is left.” - Unknown
“Any sufficiently advanced technology is indistinguishable from a rigged demo.” - James Klass
“A game is a series of interesting choices.” - Sid Meier

23

I’ll start with my vote, I’m 51% in favor of handling these combos
internally.

As an anecdote: Every game I port to the Mac with SDL 1.2 ends up with
this code…

while (SDL_PollEvent(&e)) {
switch (e.type) {
case SDL_KEYDOWN:
#ifdef APPLE
if ((e.key.keysym.sym == SDLK_q) && (e.key.keysym.mod &
KMOD_META))
doTheSameThingThatSDL_QUITHandlerWouldDo();
#endif
}
}

And, not to mention: if you want to handle the standard minimize, etc
hotkeys, you catch them much the same way, but then you have to have a
small Objective-C file to invoke the proper Cocoa:

http://hg.icculus.org/icculus/hge-unix/file/99e499f0cc69/src/core/unix/macosx_support.mm

…which is annoying if your project is otherwise all C/C++. Similar
issues exist on other platforms, and this is even more egregious on
Unix, where the proper thing to do is less clear than a standard Cocoa
or Win32 call.

My thought is that SDL should handle these things; it already handles
them for mouse clicks on the window decorations, and it prevents
annoying code that must be implemented in every app.

Perhaps a SDL_HINT_HANDLE_OS_HOTKEYS should be added (that defaults to
catching this stuff inside SDL, but can be turned off for apps that care
deeply about this stuff)?

–ryan.

24 
      case SDL_KEYDOWN:
          #ifdef __APPLE__

Two more thoughts:

  • This code is buggy, because you don’t want iOS to respond to this event.

  • If your app doesn’t respond to the Apple-Q hotkey by quitting, your
    Mac App Store submission will be rejected, so there’s an added benefit
    to SDL converting this to an SDL_QUIT event.

–ryan.

25

If I had to choose one or the other, I would go with letting the OS
deal with key presses it knows about. One of the nice things about SDL
is that it tends not to “get in the way”. Having SDL swallow the OS
combos seems to violate that.

There is precedent for both. If you send a SIGINT to an SDL app, SDL
catches it and converts it to an SDL_QUIT event, which seems way more
outrageous than catching standard hotkeys.

–ryan.

26

Fair enough, let’s make it so.

As an additional data point, most X11 window managers catch shortcuts
before they get to SDL applications, so there’s really no way to avoid
shortcut handling in that environment.

Also Apple, as Ryan said, will reject applications which don’t conform to
the system standards.

I’m fine with SDL 2.0 having well behaved OS semantics. If people really
want a hint to disable that when possible, that’s fine too, but that should
be the exception.On Sat, Jul 28, 2012 at 2:37 PM, Ryan C. Gordon wrote:

I’ll start with my vote, I’m 51% in favor of handling these combos

internally.

As an anecdote: Every game I port to the Mac with SDL 1.2 ends up with
this code…

while (SDL_PollEvent(&e)) {
switch (e.type) {
case SDL_KEYDOWN:
#ifdef APPLE
if ((e.key.keysym.sym == SDLK_q) && (e.key.keysym.mod &
KMOD_META))
doTheSameThingThatSDL_**QUITHandlerWouldDo();
#endif
}
}

And, not to mention: if you want to handle the standard minimize, etc
hotkeys, you catch them much the same way, but then you have to have a
small Objective-C file to invoke the proper Cocoa:

http://hg.icculus.org/icculus/**hge-unix/file/99e499f0cc69/**
src/core/unix/macosx_support.**mmhttp://hg.icculus.org/icculus/hge-unix/file/99e499f0cc69/src/core/unix/macosx_support.mm

…which is annoying if your project is otherwise all C/C++. Similar
issues exist on other platforms, and this is even more egregious on Unix,
where the proper thing to do is less clear than a standard Cocoa or Win32
call.

My thought is that SDL should handle these things; it already handles
them for mouse clicks on the window decorations, and it prevents annoying
code that must be implemented in every app.

Perhaps a SDL_HINT_HANDLE_OS_HOTKEYS should be added (that defaults to
catching this stuff inside SDL, but can be turned off for apps that care
deeply about this stuff)?

–ryan.

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

27

Glad to see you’re in agreement here.? :)________________________________
From: Sam Lantinga
To: SDL Development List
Sent: Tuesday, July 31, 2012 7:44 PM
Subject: Re: [SDL] Should SDL2 handle standard keyboard shortcuts?

Fair enough, let’s make it so.

As an additional data point, most X11 window managers catch shortcuts before they get to SDL applications, so there’s really no way to avoid shortcut handling in that environment.

Also Apple, as Ryan said, will reject applications which don’t conform to the system standards.

I’m fine with SDL 2.0 having well behaved OS semantics. ?If people really want a hint to disable that when possible, that’s fine too, but that should be the exception.

On Sat, Jul 28, 2012 at 2:37 PM, Ryan C. Gordon wrote:

I’ll start with my vote, I’m 51% in favor of handling these combos

internally.

As an anecdote: Every game I port to the Mac with SDL 1.2 ends up with this code…

while (SDL_PollEvent(&e)) {
? ? switch (e.type) {
? ? ? ? case SDL_KEYDOWN:
? ? ? ? ? ? #ifdef APPLE
? ? ? ? ? ? if ((e.key.keysym.sym == SDLK_q) && (e.key.keysym.mod & KMOD_META))
? ? ? ? ? ? ? ? doTheSameThingThatSDL_QUITHandlerWouldDo();
? ? ? ? ? ? #endif
? ? ?}
}

And, not to mention: if you want to handle the standard minimize, etc hotkeys, you catch them much the same way, but then you have to have a small Objective-C file to invoke the proper Cocoa:

http://hg.icculus.org/icculus/hge-unix/file/99e499f0cc69/src/core/unix/macosx_support.mm

…which is annoying if your project is otherwise all C/C++. Similar issues exist on other platforms, and this is even more egregious on Unix, where the proper thing to do is less clear than a standard Cocoa or Win32 call.

My thought is that SDL should handle these things; it already handles them for mouse clicks on the window decorations, and it prevents annoying code that must be implemented in every app.

Perhaps a SDL_HINT_HANDLE_OS_HOTKEYS should be added (that defaults to catching this stuff inside SDL, but can be turned off for apps that care deeply about this stuff)?

–ryan.

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

28

Unless you put put the SDL window to fullscreen. Then the SDL grabs keyboard
input, so the window manager cannot handle it. This realy irritates me.

– PetrOn Tue, Jul 31, 2012 at 10:44:54PM -0400, Sam Lantinga wrote:

As an additional data point, most X11 window managers catch shortcuts
before they get to SDL applications, so there’s really no way to avoid
shortcut handling in that environment.

29

I think i tricked you. i said i don’t want it because i do want it. Too
late to back up now. My real opinion is that sdl should act like most apps
do in each enviroment so people get what they expect unless the coder
decides different. My opinion is that sdl is here to handle that stuff so i
don’t have to. 100% for it :)On Tue, Jul 31, 2012 at 9:44 PM, Sam Lantinga wrote:

Fair enough, let’s make it so.

As an additional data point, most X11 window managers catch shortcuts
before they get to SDL applications, so there’s really no way to avoid
shortcut handling in that environment.

Also Apple, as Ryan said, will reject applications which don’t conform to
the system standards.

I’m fine with SDL 2.0 having well behaved OS semantics. If people really
want a hint to disable that when possible, that’s fine too, but that should
be the exception.

On Sat, Jul 28, 2012 at 2:37 PM, Ryan C. Gordon wrote:

I’ll start with my vote, I’m 51% in favor of handling these combos

internally.

As an anecdote: Every game I port to the Mac with SDL 1.2 ends up with
this code…

while (SDL_PollEvent(&e)) {
switch (e.type) {
case SDL_KEYDOWN:
#ifdef APPLE
if ((e.key.keysym.sym == SDLK_q) && (e.key.keysym.mod &
KMOD_META))
doTheSameThingThatSDL_**QUITHandlerWouldDo();
#endif
}
}

And, not to mention: if you want to handle the standard minimize, etc
hotkeys, you catch them much the same way, but then you have to have a
small Objective-C file to invoke the proper Cocoa:

http://hg.icculus.org/icculus/**hge-unix/file/99e499f0cc69/**
src/core/unix/macosx_support.**mmhttp://hg.icculus.org/icculus/hge-unix/file/99e499f0cc69/src/core/unix/macosx_support.mm

…which is annoying if your project is otherwise all C/C++. Similar
issues exist on other platforms, and this is even more egregious on Unix,
where the proper thing to do is less clear than a standard Cocoa or Win32
call.

My thought is that SDL should handle these things; it already handles
them for mouse clicks on the window decorations, and it prevents annoying
code that must be implemented in every app.

Perhaps a SDL_HINT_HANDLE_OS_HOTKEYS should be added (that defaults to
catching this stuff inside SDL, but can be turned off for apps that care
deeply about this stuff)?

–ryan.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://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

30

I just checked in a change to SDL 2.0 so that it will automatically set up
menu key shortcuts and handle this stuff for you.

I left in the hack where we handle key events before passing them on to the
NSApp, mostly because the normal processing eats the escape key and turns
it into a cancel operation. So your app will see key events for shortcuts
even though technically it’s not supposed to.

Cheers!On Sat, Jul 28, 2012 at 11:37 AM, Ryan C. Gordon wrote:

I’ll start with my vote, I’m 51% in favor of handling these combos

internally.

As an anecdote: Every game I port to the Mac with SDL 1.2 ends up with
this code…

while (SDL_PollEvent(&e)) {
switch (e.type) {
case SDL_KEYDOWN:
#ifdef APPLE
if ((e.key.keysym.sym == SDLK_q) && (e.key.keysym.mod &
KMOD_META))
doTheSameThingThatSDL_**QUITHandlerWouldDo();
#endif
}
}

And, not to mention: if you want to handle the standard minimize, etc
hotkeys, you catch them much the same way, but then you have to have a
small Objective-C file to invoke the proper Cocoa:

http://hg.icculus.org/icculus/**hge-unix/file/99e499f0cc69/**
src/core/unix/macosx_support.**mmhttp://hg.icculus.org/icculus/hge-unix/file/99e499f0cc69/src/core/unix/macosx_support.mm

…which is annoying if your project is otherwise all C/C++. Similar
issues exist on other platforms, and this is even more egregious on Unix,
where the proper thing to do is less clear than a standard Cocoa or Win32
call.

My thought is that SDL should handle these things; it already handles
them for mouse clicks on the window decorations, and it prevents annoying
code that must be implemented in every app.

Perhaps a SDL_HINT_HANDLE_OS_HOTKEYS should be added (that defaults to
catching this stuff inside SDL, but can be turned off for apps that care
deeply about this stuff)?

–ryan.

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

31

Hello,

This thread is 10 years old, is there any update on how to deal with shortcut in OSX with SDL2?

Also what should we put in “doTheSameThingThatSDL_**QUITHandlerWouldDo();” ?