Cocoa gurus: Bugzilla #1825...?

Any Cocoa hackers out there that can give us some insight on this bug?

 http://bugzilla.libsdl.org/show_bug.cgi?id=1825

Basically: Closing a window in an SDL app doesn’t make the next
application window down in the z-order the key window. It’s not clear if
there’s some action we should have taken but failed to, or something
we’re doing that confuses Cocoa. Even the app’s “About” dialog won’t
bring the focus back to our app windows when you close it.

I’ve never seen another Mac OS X app that works like that, and Google
doesn’t even find discussion about window focus handling at all, which
means this is probably something usually automated that we threw a
wrench in.

It’s probably something simple, but I’ve run out of Google luck. Anyone
have any insight?

Thanks,
–ryan.

I don’t have a solution, but I isolated the cause. I updated the bug
information with what I found.

Thanks,
EricOn 7/20/13, Ryan C. Gordon wrote:

Any Cocoa hackers out there that can give us some insight on this bug?

 http://bugzilla.libsdl.org/show_bug.cgi?id=1825

Basically: Closing a window in an SDL app doesn’t make the next
application window down in the z-order the key window. It’s not clear if
there’s some action we should have taken but failed to, or something
we’re doing that confuses Cocoa. Even the app’s “About” dialog won’t
bring the focus back to our app windows when you close it.

I’ve never seen another Mac OS X app that works like that, and Google
doesn’t even find discussion about window focus handling at all, which
means this is probably something usually automated that we threw a
wrench in.

It’s probably something simple, but I’ve run out of Google luck. Anyone
have any insight?

Thanks,
–ryan.


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


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Eric, [NSApp updateWindows] is useless by default. the NSWindow implementation of update does nothing but post a notification.

you may be onto something with the runloop tho. I vaguely recall having this problem with a game (an SDL 1.2 game at that) that was implementing its own runloop; IIRC i worked around the problem by pigybacking on the default runloop. I can try building that app with SDL2 and see if it still works.

you can get an in-order-list of windows (sans some special windows) with [NSApp orderedWindows] if it will help you work around the problem manually.

one thing you are probably missing (i know erics sample code is) you need to call [NSApp finishLaunching] before starting a runloop.

this article (“http://www.cocoawithlove.com/2009/01/demystifying-nsapplication-by.html”) may provide some insight into the problem

[NSApp finishLaunching] is already in the SDL code base. And it
doesn’t seem to make a difference in my test app.

Yes, CocoaWithLove has the most extensive public analysis I’ve ever
seen on deconstructing the inner-workings of the Cocoa scaffolding. My
test program actually contains two different links to cocoawithlove.

Thanks,
EricOn 7/22/13, brada wrote:

one thing you are probably missing (i know erics sample code is) you need to
call [NSApp finishLaunching] before starting a runloop.

this article
(“http://www.cocoawithlove.com/2009/01/demystifying-nsapplication-by.html”)
may provide some insight into the problem


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

you can get an in-order-list of windows (sans some special windows) with
[NSApp orderedWindows] if it will help you work around the problem manually.

Ooh, I didn’t see that.

Here’s a fix for SDL2 (attached).

–ryan.

-------------- next part --------------

HG changeset patch

User Ryan C. Gordon <@icculus>

Date 1374540907 14400

Node ID a3c4494f54202fc1ff847ab6494ee37e20fc8a48

Parent 6b484ff38f86a8250f348e787600355c8ed45f30

Cocoa: Make the next-highest window gain focus when a window is closing.

(if the closed window wasn’t the foreground, this is effectively a no-op.)

diff --git a/src/video/cocoa/SDL_cocoawindow.m b/src/video/cocoa/SDL_cocoawindow.m
— a/src/video/cocoa/SDL_cocoawindow.m
+++ b/src/video/cocoa/SDL_cocoawindow.m
@@ -133,6 +133,7 @@
NSNotificationCenter *center;
NSWindow *window = _data->nswindow;
NSView *view = [window contentView];

  • NSArray *windows = nil;

    center = [NSNotificationCenter defaultCenter];

@@ -157,6 +158,12 @@
if ([view nextResponder] == self) {
[view setNextResponder:nil];
}+

  • windows = [NSApp orderedWindows];
  • if ([windows count] > 0) {
  •    NSWindow *win = (NSWindow *) [windows objectAtIndex:0];
    
  •    [win makeKeyAndOrderFront:self];
    
  • }
    }
  • (BOOL)windowShouldClose:(id)sender

This doesn’t solve the about box problem or handle message boxes that
aren’t parented, but if we can’t figure it out before ship, let’s apply it.

Cheers!On Mon, Jul 22, 2013 at 6:06 PM, Ryan C. Gordon wrote:

you can get an in-order-list of windows (sans some special windows) with

[NSApp orderedWindows] if it will help you work around the problem
manually.

Ooh, I didn’t see that.

Here’s a fix for SDL2 (attached).

–ryan.


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