ESC key minimizes SDL Fullscreen app after using TextInput

Hi,

I’m using SDL2 on Mac 10.10 Yosemite. Everything works fine, except one strange behavior:

I run the game in desktop fullscreen mode:

SDL_CreateWindowAndRenderer(0, 0, SDL_WINDOW_FULLSCREEN_DESKTOP, &sdlWindow, &sdlRenderer);

Everything works fine until I use SDL_StartTextInput() to get some text from the user. I finish that with SDL_StopTextInput() and after that point pressing the ESC key minimizes the whole game. This keeps happening until I restart the application completely.

I searched the internet, and it seems that ESC is used to exit fullscreen for OSX apps, but SDL somehow blocks that properly until SDL_*TextInput() stuff is used.

It seems to affect some well known SDL apps:

http://steamcommunity.com/app/570/discussions/0/558746745556604920/

But I have no clue how they fixed it. Any ideas what to test or how to work around this?------------------------
bigosaur.com

Are you using SDL 2.0.3 or the latest Mercurial code (2.0.4)? If the former, does it still happen for you if you use the latest SDL code from Mercurial?

Doing a quick test in my own code (which uses SDL’s latest Mercurial code), I can?t reproduce the problem.> On Feb 9, 2015, at 12:08 PM, mbabuskov <milan.babuskov at gmail.com> wrote:

Hi,

I’m using SDL2 on Mac 10.10 Yosemite. Everything works fine, except one strange behavior:

I run the game in desktop fullscreen mode:

SDL_CreateWindowAndRenderer(0, 0, SDL_WINDOW_FULLSCREEN_DESKTOP, &sdlWindow, &sdlRenderer);

Everything works fine until I use SDL_StartTextInput() to get some text from the user. I finish that with SDL_StopTextInput() and after that point pressing the ESC key minimizes the whole game. This keeps happening until I restart the application completely.

I searched the internet, and it seems that ESC is used to exit fullscreen for OSX apps, but SDL somehow blocks that properly until SDL_*TextInput() stuff is used.

It seems to affect some well known SDL apps:

http://steamcommunity.com/app/570/discussions/0/558746745556604920/ http://steamcommunity.com/app/570/discussions/0/558746745556604920/

But I have no clue how they fixed it. Any ideas what to test or how to work around this?

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

Alex Szpakowski wrote:

Are you using SDL 2.0.3 or the latest Mercurial code (2.0.4)? If the former, does it still happen for you if you use the latest SDL code from Mercurial?

I’m using 2.0.3. It seems that this bug is only visible on OSX 10.10. Are you on Yosemite?

I’ll try to compile 2.0.4, but I’m new to Mac so I need to first learn how to safely remove it later.

Thanks.------------------------
bigosaur.com

Yeah, OS X 10.10.2.> On Feb 28, 2015, at 4:49 AM, mbabuskov <milan.babuskov at gmail.com> wrote:

I’m using 2.0.3. It seems that this bug is only visible on OSX 10.10. Are you on Yosemite?

I’ll try to compile 2.0.4, but I’m new to Mac so I need to first learn how to safely remove it later.

Thanks.

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

I?ve had this problem as well, and can reproduce it across multiple applications - without needed TextInput. It seems specific to SDL_FULLSCREEN_DESKTOP (where it triggers a transition to a new space). It?s fairly subtle, in part because switching out of the space and back into it will cause it to behave correctly.

I don?t know a ton about AppKit, but it appears that it is a problem with the responder chain that causes the escape key to default to the system defined behavior of closing the space/exiting the fullscreen mode. The short version is that the Escape key (along with Command-.) cause the system to try to send the cancelOperation https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/index.html#//apple_ref/occ/instm/NSResponder/cancelOperation: message and cancel messages to the first responder chain. Upon failing, it simply takes the window out of fullscreen mode as this is the default system behavior. I?d have to dig into it again, but I believe I had found a work around the behavior by implementing acceptsFirstResponder https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/index.html#//apple_ref/occ/instp/NSResponder/acceptsFirstResponder in the Cocoa_WindowListener class. I might have also required implementing cancelOperation to make it so that it ignores that message in the first place. I don?t have a fixed version handy though, so I?m not sure, but I had found references to the fullscreen API creating a whole new window when it goes fullscreen, so the responder chain winds up being recreated every time there is a transition.

Unfortunately, I don?t actually know much about Cocoa/AppKit so I?m a little hesitant to suggest this is actually what?s going on.

(Also, as a side note, it?s a little sad that SDL doesn?t send the window resize event to the application until after the transition to the fullscreen space is complete. This, unfortunately, can cause the window contents used during the transition to be very, very wrong)

-Luke> On Feb 28, 2015, at 1:52 AM, Alex Szpakowski wrote:

Yeah, OS X 10.10.2.

On Feb 28, 2015, at 4:49 AM, mbabuskov <milan.babuskov at gmail.com <mailto:milan.babuskov at gmail.com>> wrote:

I’m using 2.0.3. It seems that this bug is only visible on OSX 10.10. Are you on Yosemite?

I’ll try to compile 2.0.4, but I’m new to Mac so I need to first learn how to safely remove it later.

Thanks.

bigosaur.com http://bigosaur.com/_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-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

Have you tried reproducing the problem with the latest SDL 2.0.4 Mercurial code?

(Another thing that the latest SDL 2.0.4 code changes is the way that fullscreen-desktop transitions are handled in OS X. It now blocks during the transition so the app won?t be able to do anything that causes unexpected behaviour during the transition. I highly recommend using the latest SDL 2.0.4 rather than 2.0.3 in OS X.)> On Feb 28, 2015, at 3:20 PM, Luke Groeninger wrote:

I?ve had this problem as well, and can reproduce it across multiple applications - without needed TextInput. It seems specific to SDL_FULLSCREEN_DESKTOP (where it triggers a transition to a new space). It?s fairly subtle, in part because switching out of the space and back into it will cause it to behave correctly.

I don?t know a ton about AppKit, but it appears that it is a problem with the responder chain that causes the escape key to default to the system defined behavior of closing the space/exiting the fullscreen mode. The short version is that the Escape key (along with Command-.) cause the system to try to send the cancelOperation https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/index.html#//apple_ref/occ/instm/NSResponder/cancelOperation: message and cancel messages to the first responder chain. Upon failing, it simply takes the window out of fullscreen mode as this is the default system behavior. I?d have to dig into it again, but I believe I had found a work around the behavior by implementing acceptsFirstResponder https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/index.html#//apple_ref/occ/instp/NSResponder/acceptsFirstResponder in the Cocoa_WindowListener class. I might have also required implementing cancelOperation to make it so that it ignores that message in the first place. I don?t have a fixed version handy though, so I?m not sure, but I had found references to the fullscreen API creating a whole new window when it goes fullscreen, so the responder chain winds up being recreated every time there is a transition.

Unfortunately, I don?t actually know much about Cocoa/AppKit so I?m a little hesitant to suggest this is actually what?s going on.

(Also, as a side note, it?s a little sad that SDL doesn?t send the window resize event to the application until after the transition to the fullscreen space is complete. This, unfortunately, can cause the window contents used during the transition to be very, very wrong)

-Luke

On Feb 28, 2015, at 1:52 AM, Alex Szpakowski <@Alex_Szpakowski mailto:Alex_Szpakowski> wrote:

Yeah, OS X 10.10.2.

On Feb 28, 2015, at 4:49 AM, mbabuskov <milan.babuskov at gmail.com <mailto:milan.babuskov at gmail.com>> wrote:

I’m using 2.0.3. It seems that this bug is only visible on OSX 10.10. Are you on Yosemite?

I’ll try to compile 2.0.4, but I’m new to Mac so I need to first learn how to safely remove it later.

Thanks.

bigosaur.com http://bigosaur.com/_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-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

fullscreen is evil, loose your window decorations and maximize, even loose
window title and make the close button hang over the top of the game screen
by moving it minus it’s size

and all you morons that make games default as too big for a small screen so
actually click on make screen smaller in the window, sort it out, how do i
press okay to make the screen smaller if the screen is too big and i can
get to the button

cant you people detect i have a freaking stupid small screen and not boot
up in oversized size? i mean its not irritating as dual to load a game from
apt then not be able to change the screen size without searching the source
code for comman line options then having to launch a custom launcher to
make sure the game is actually playable each time i load it, which then
become inoperable when the game gets updated

sorry not ranting just about to put my coding gloves on and need to be back
in joy computers mind set

top props to sam ryan and the crewOn Sat, Feb 28, 2015 at 11:28 AM, Alex Szpakowski wrote:

Have you tried reproducing the problem with the latest SDL 2.0.4 Mercurial
code?

(Another thing that the latest SDL 2.0.4 code changes is the way that
fullscreen-desktop transitions are handled in OS X. It now blocks during
the transition so the app won?t be able to do anything that causes
unexpected behaviour during the transition. I highly recommend using the
latest SDL 2.0.4 rather than 2.0.3 in OS X.)

On Feb 28, 2015, at 3:20 PM, Luke Groeninger wrote:

I?ve had this problem as well, and can reproduce it across multiple
applications - without needed TextInput. It seems specific to
SDL_FULLSCREEN_DESKTOP (where it triggers a transition to a new space).
It?s fairly subtle, in part because switching out of the space and back
into it will cause it to behave correctly.

I don?t know a ton about AppKit, but it appears that it is a problem with
the responder chain that causes the escape key to default to the system
defined behavior of closing the space/exiting the fullscreen mode. The
short version is that the Escape key (along with Command-.) cause the
system to try to send the cancelOperation
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/index.html#//apple_ref/occ/instm/NSResponder/cancelOperation: message and
cancel messages to the first responder chain. Upon failing, it simply takes
the window out of fullscreen mode as this is the default system behavior.
I?d have to dig into it again, but I believe I had found a work around the
behavior by implementing acceptsFirstResponder
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/index.html#//apple_ref/occ/instp/NSResponder/acceptsFirstResponder in
the Cocoa_WindowListener class. I might have also required implementing
cancelOperation to make it so that it ignores that message in the first
place. I don?t have a fixed version handy though, so I?m not sure, but I
had found references to the fullscreen API creating a whole new window when
it goes fullscreen, so the responder chain winds up being recreated every
time there is a transition.

Unfortunately, I don?t actually know much about Cocoa/AppKit so I?m a
little hesitant to suggest this is actually what?s going on.

(Also, as a side note, it?s a little sad that SDL doesn?t send the window
resize event to the application until after the transition to the
fullscreen space is complete. This, unfortunately, can cause the window
contents used during the transition to be very, very wrong)

-Luke

On Feb 28, 2015, at 1:52 AM, Alex Szpakowski wrote:

Yeah, OS X 10.10.2.

On Feb 28, 2015, at 4:49 AM, mbabuskov <milan.babuskov at gmail.com> wrote:

I’m using 2.0.3. It seems that this bug is only visible on OSX 10.10. Are
you on Yosemite?

I’ll try to compile 2.0.4, but I’m new to Mac so I need to first learn how
to safely remove it later.

Thanks.


bigosaur.com


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


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

Quick and dirty 5 minute test suggest it doesn?t. It also doesn?t animate the transition into the fullscreen space either, so that?s a HUGE improvement.

I?ll keep testing against 2.0.4 and let you know if I can get it to break.

-Luke> On Feb 28, 2015, at 12:28 PM, Alex Szpakowski wrote:

Have you tried reproducing the problem with the latest SDL 2.0.4 Mercurial code?

(Another thing that the latest SDL 2.0.4 code changes is the way that fullscreen-desktop transitions are handled in OS X. It now blocks during the transition so the app won?t be able to do anything that causes unexpected behaviour during the transition. I highly recommend using the latest SDL 2.0.4 rather than 2.0.3 in OS X.)

On Feb 28, 2015, at 3:20 PM, Luke Groeninger <@Luke_Groeninger mailto:Luke_Groeninger> wrote:

I?ve had this problem as well, and can reproduce it across multiple applications - without needed TextInput. It seems specific to SDL_FULLSCREEN_DESKTOP (where it triggers a transition to a new space). It?s fairly subtle, in part because switching out of the space and back into it will cause it to behave correctly.

I don?t know a ton about AppKit, but it appears that it is a problem with the responder chain that causes the escape key to default to the system defined behavior of closing the space/exiting the fullscreen mode. The short version is that the Escape key (along with Command-.) cause the system to try to send the cancelOperation https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/index.html#//apple_ref/occ/instm/NSResponder/cancelOperation: message and cancel messages to the first responder chain. Upon failing, it simply takes the window out of fullscreen mode as this is the default system behavior. I?d have to dig into it again, but I believe I had found a work around the behavior by implementing acceptsFirstResponder https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/index.html#//apple_ref/occ/instp/NSResponder/acceptsFirstResponder in the Cocoa_WindowListener class. I might have also required implementing cancelOperation to make it so that it ignores that message in the first place. I don?t have a fixed version handy though, so I?m not sure, but I had found references to the fullscreen API creating a whole new window when it goes fullscreen, so the responder chain winds up being recreated every time there is a transition.

Unfortunately, I don?t actually know much about Cocoa/AppKit so I?m a little hesitant to suggest this is actually what?s going on.

(Also, as a side note, it?s a little sad that SDL doesn?t send the window resize event to the application until after the transition to the fullscreen space is complete. This, unfortunately, can cause the window contents used during the transition to be very, very wrong)

-Luke

On Feb 28, 2015, at 1:52 AM, Alex Szpakowski <aszpakowski at gmail.com <mailto:aszpakowski at gmail.com>> wrote:

Yeah, OS X 10.10.2.

On Feb 28, 2015, at 4:49 AM, mbabuskov <milan.babuskov at gmail.com <mailto:milan.babuskov at gmail.com>> wrote:

I’m using 2.0.3. It seems that this bug is only visible on OSX 10.10. Are you on Yosemite?

I’ll try to compile 2.0.4, but I’m new to Mac so I need to first learn how to safely remove it later.

Thanks.

bigosaur.com http://bigosaur.com/_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-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 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