I am using SDL 2.0.1 on Mac OS X.
When I alt-tab away from my SDL_FULLSCREEN_DESKTOP application and return
to it by selecting the application from the Dock, the application no longer
receives mouse events.
If I alt-tab back to the application, the mouse continues to receive mouse
events.
Is there anything I can do to fix this, or to help nail down the problem?
Thanks
John
Have you tried SDL 2.0.2?On Mar 11, 2014, at 3:16 PM, John Knottenbelt wrote:
I am using SDL 2.0.1 on Mac OS X.
When I alt-tab away from my SDL_FULLSCREEN_DESKTOP application and return to it by selecting the application from the Dock, the application no longer receives mouse events.
If I alt-tab back to the application, the mouse continues to receive mouse events.
Is there anything I can do to fix this, or to help nail down the problem?
Thanks
John
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I tried SDL 2.0.2 today and I get the same problem. I did some more
investigation and refined the steps to reproduce. The problem is most
easily reproduced with Mac OS X 10.9.2. It is not actually required to run
the application fullscreen as I initially thought. Here are some repro
steps for windowed mode:
Have you tried SDL 2.0.2?
On Mar 11, 2014, at 3:16 PM, John Knottenbelt <@John_Knottenbelt> wrote:
I am using SDL 2.0.1 on Mac OS X.
When I alt-tab away from my SDL_FULLSCREEN_DESKTOP application and
return to it by selecting the application from the Dock, the application no
longer receives mouse events.If I alt-tab back to the application, the mouse continues to receive
mouse events.Is there anything I can do to fix this, or to help nail down the problem?
Thanks
John
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
So this won’t solve your problem (at least not yet) but may give some
hints. I am currently prototyping to turn SDL inside-out so 1) I can
embed SDL views in native/existing apps/frameworks, 2) use the
platform’s native event pump because the current SDL model of
explicitly pumping the event loop actually causes a lot of corner
cases which have caused things like focus problems on Mac/iOS and some
related concerns I have on Android. (I hope to start a public
proposal/discussion to the mailing list in a couple of weeks.)
Meanwhile, using my prototype to try to reproduce your problem, I do
not experience it. My first two guesses for this are:
-EricOn 3/12/14, John Knottenbelt wrote:
I tried SDL 2.0.2 today and I get the same problem. I did some more
investigation and refined the steps to reproduce. The problem is most
easily reproduced with Mac OS X 10.9.2. It is not actually required to run
the application fullscreen as I initially thought. Here are some repro
steps for windowed mode:
- Run the SDL application in windowed mode.
- Minimise the application using the yellow minus sign at the top
left-corner of the window.- Focus another application (e.g. click on something else such as
Terminal).- Click on the thumbnail image of the application, just next to the Trash
can, in the dock (not than the application icon).- Notice that the application does not receive the window focus, although
it is the active window.
–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
Thanks for the hints! I’m not very familiar with the Cocoa and objective c
APIs, but I did some more investigation. Maybe it will help:
I also downloaded SDL from mecurial and put in a bunch of SDL_logs.
I discovered that when the application is minimised the window gives up
’key’ status, but when it is restored from its thumbnail in the dock, it
does not receive a windowDidBecomeKey event. I tried calling this manually
from windowDidMiniaturize, but this didn’t help.
Another thing I noticed is that the Cocoa_HandleMouseEvent is being called
while the mouse is outside of the application (and NSView: mouseMoved), but
when the mouse enters the game window, these events stop.On Thu, Mar 13, 2014 at 4:53 AM, Eric Wing wrote:
On 3/12/14, John Knottenbelt <@John_Knottenbelt> wrote:
I tried SDL 2.0.2 today and I get the same problem. I did some more
investigation and refined the steps to reproduce. The problem is most
easily reproduced with Mac OS X 10.9.2. It is not actually required to
run
the application fullscreen as I initially thought. Here are some repro
steps for windowed mode:
- Run the SDL application in windowed mode.
- Minimise the application using the yellow minus sign at the top
left-corner of the window.- Focus another application (e.g. click on something else such as
Terminal).- Click on the thumbnail image of the application, just next to the
Trash
can, in the dock (not than the application icon).- Notice that the application does not receive the window focus,
although
it is the active window.So this won’t solve your problem (at least not yet) but may give some
hints. I am currently prototyping to turn SDL inside-out so 1) I can
embed SDL views in native/existing apps/frameworks, 2) use the
platform’s native event pump because the current SDL model of
explicitly pumping the event loop actually causes a lot of corner
cases which have caused things like focus problems on Mac/iOS and some
related concerns I have on Android. (I hope to start a public
proposal/discussion to the mailing list in a couple of weeks.)Meanwhile, using my prototype to try to reproduce your problem, I do
not experience it. My first two guesses for this are:
- The manual event pumping is once again getting in the way
- The way the NSResponder chain is setup on SDL/Mac is a little
unusual for Cocoa applications. In SDL, the responder is actually a
separate object from the window and the view. More typically, the
responder is the NSView itself. It could be because the NSResponder is
a separate object from both the view and the window, something is not
being propagated correctly. If this was actually a fullscreen issue,
my guess would have been the window got destroyed and recreated but
the responder was not re-created or re-associated with the new window,
but since this is happening on minimization, I think this is less
likely. But my prototype modifications simplified the responder system
so the NSView itself handles the logic which could explain why I’m not
reproducing your bug.-Eric
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I inserted some more debugging and I have traces of the good flow
(restoring from the application icon) and the bad flow (restoring from the
thumbnail in the dock):
Good flow:
CocoaEvents: FocusSomeWindow. seenFirstActivate = 1
Cocoa_RestoreWindow
Deminiaturize
NSWindow observeValueForKeyPath visible changed to 1
SDL_OnWindowShown - calling SDL_OnWindowRestored
SDL_OnWindowRestored
Cocoa_RaiseWindow
Window Did Become Key
NSWindow observeValueForKeyPath visible changed to 1
NSWindow observeValueForKeyPath visible changed to 1
NSWindow observeValueForKeyPath visible changed to 1
NSWindow: windowDidDeminiaturize
NSWindow: windowDidDeminiaturize - sending restored event.
SDL_OnWindowRestored
Cocoa_RaiseWindow
Window 2 gained keyboard focus
Window 2 shown
Window 2 restored
Bad flow:
NSWindow observeValueForKeyPath visible changed to 1
SDL_OnWindowShown - calling SDL_OnWindowRestored
SDL_OnWindowRestored
Cocoa_RaiseWindow
CocoaEvents: FocusSomeWindow. seenFirstActivate = 1
Cocoa_RestoreWindow
Window is not miniaturized.
NSWindow observeValueForKeyPath visible changed to 1
NSWindow observeValueForKeyPath visible changed to 1
NSWindow observeValueForKeyPath visible changed to 1
NSWindow observeValueForKeyPath visible changed to 1
NSWindow observeValueForKeyPath visible changed to 1
NSWindow observeValueForKeyPath visible changed to 1
NSWindow: windowDidDeminiaturize
NSWindow: windowDidDeminiaturize - sending restored event.
SDL_OnWindowRestored
Cocoa_RaiseWindow
CocoaEvents: FocusSomeWindow. seenFirstActivate = 1
Cocoa_RaiseWindow
Window 2 shown
Window 2 restored
It seems that in the bad flow, it is the window manager that is actually
making the window visible, rather than it being driven by SDL due to the
application being activated. I notice that I can fix this problem by making
the Cocoa_RaiseWindow function not request that the window become key. That
is, if I remove the line:
[nswindow makeKeyAndOrderFront:nil]
or replace it with
[nswindow orderFront:nil]
Everything works fine. I’m not entirely sure why though!
Does this shed any light on what’s going wrong?On Thu, Mar 13, 2014 at 4:16 PM, John Knottenbelt <@John_Knottenbelt>wrote:
Thanks for the hints! I’m not very familiar with the Cocoa and objective c
APIs, but I did some more investigation. Maybe it will help:
- Mouse wheel, Middle mouse button and Right mouse button do work, and I
get mouse motion events if either the middle mouse button or left mouse
button is pressed.- Left mouse button does actually work, but I have to hit double tap
quickly before it comes through.I also downloaded SDL from mecurial and put in a bunch of SDL_logs.
I discovered that when the application is minimised the window gives up
’key’ status, but when it is restored from its thumbnail in the dock, it
does not receive a windowDidBecomeKey event. I tried calling this manually
from windowDidMiniaturize, but this didn’t help.Another thing I noticed is that the Cocoa_HandleMouseEvent is being called
while the mouse is outside of the application (and NSView: mouseMoved), but
when the mouse enters the game window, these events stop.On Thu, Mar 13, 2014 at 4:53 AM, Eric Wing wrote:
On 3/12/14, John Knottenbelt <@John_Knottenbelt> wrote:
I tried SDL 2.0.2 today and I get the same problem. I did some more
investigation and refined the steps to reproduce. The problem is most
easily reproduced with Mac OS X 10.9.2. It is not actually required to
run
the application fullscreen as I initially thought. Here are some repro
steps for windowed mode:
- Run the SDL application in windowed mode.
- Minimise the application using the yellow minus sign at the top
left-corner of the window.- Focus another application (e.g. click on something else such as
Terminal).- Click on the thumbnail image of the application, just next to the
Trash
can, in the dock (not than the application icon).- Notice that the application does not receive the window focus,
although
it is the active window.So this won’t solve your problem (at least not yet) but may give some
hints. I am currently prototyping to turn SDL inside-out so 1) I can
embed SDL views in native/existing apps/frameworks, 2) use the
platform’s native event pump because the current SDL model of
explicitly pumping the event loop actually causes a lot of corner
cases which have caused things like focus problems on Mac/iOS and some
related concerns I have on Android. (I hope to start a public
proposal/discussion to the mailing list in a couple of weeks.)Meanwhile, using my prototype to try to reproduce your problem, I do
not experience it. My first two guesses for this are:
- The manual event pumping is once again getting in the way
- The way the NSResponder chain is setup on SDL/Mac is a little
unusual for Cocoa applications. In SDL, the responder is actually a
separate object from the window and the view. More typically, the
responder is the NSView itself. It could be because the NSResponder is
a separate object from both the view and the window, something is not
being propagated correctly. If this was actually a fullscreen issue,
my guess would have been the window got destroyed and recreated but
the responder was not re-created or re-associated with the new window,
but since this is happening on minimization, I think this is less
likely. But my prototype modifications simplified the responder system
so the NSView itself handles the logic which could explain why I’m not
reproducing your bug.-Eric
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
[nswindow makeKeyAndOrderFront:nil]
or replace it with
[nswindow orderFront:nil]
Everything works fine. I’m not entirely sure why though!
Does this shed any light on what’s going wrong?
Nothing is jumping out at me but I’d probably have to sit down with it
for a lot longer than my glance. I’m actually a little disturbed that
this little change makes such a big difference in breaking the
behavior. The first is supposed to give focus, the latter just brings
it to the front without necessarily giving focus. I think focus is
always desired so I would instinctively use the first version.
-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
Apologies for the long delay in response, I have been on holiday and today
was the first day I was able to investigate further.
As far as I can tell, the difference between the two situations is that
when the user restores the application from by clicking on the minimized
window thumbnail, there is an immediate observation of change in 'visible’
property that ultimately calls SDL_RaiseWindow. This then attempts to make
the window key and front, but the application is not yet active ([NSApp
isActive] returns false). The window never actually becomes key once this
state is reached.
Another possible change that fixes the problem is to suppress visiblity
observation while the application is inactive. That is, in
observeValueForKeyPath in SDL_cocoawindow.m to add:
if (![NSApp isActive]) {
return;
}
Should I file this issue as a bug in the bugzilla?On Sat, Mar 15, 2014 at 1:03 AM, Eric Wing wrote:
[nswindow makeKeyAndOrderFront:nil]
or replace it with
[nswindow orderFront:nil]
Everything works fine. I’m not entirely sure why though!
Does this shed any light on what’s going wrong?
Nothing is jumping out at me but I’d probably have to sit down with it
for a lot longer than my glance. I’m actually a little disturbed that
this little change makes such a big difference in breaking the
behavior. The first is supposed to give focus, the latter just brings
it to the front without necessarily giving focus. I think focus is
always desired so I would instinctively use the first version.-Eric
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org