sometimes, on lanch an executable file could not get window focus

[dazkzi]

on mac，open an executable file, in the meantime move the mouse，the new window will not get focus

this will not happen when using sdl2 or glfw

[floooh]

Do you build the executable as a command line application, or as a an application bundle? I seem to remember that I have seen this behaviour with command line builds, but not with regular app bundles.

Also, if you already build as app bundle, what does your .plist config file look like?

[dazkzi]

This only occurs on the command line executable, the bundle is fine.

GLFW and SDL2 are working fine when start the executable from command line.

[floooh]

Ok, I'll try to find out what GLFW does differently on startup than sokol_app.h, it might be some attribute that's normally provided by the .plist file but needs to be set programmatically otherwise.

[floooh]

Hmm, I can't seem to reproduce the issue here. I'm compiling the events-sapp.c sample as cmdline app (not as app bundle), and the window has focus right from the start (e.g. just moving the mouse reports mouse events to the app).

Can you help me reproduce the issue? For instance, what macOS and Xcode version are you on? (I'm on macOS Ventura 13.1 and Xcode 14.0.1).

[dazkzi]

I found that if it takes too much time in init, this thing will happen. Such as add this empty loop in init.

for (int i = 0; i < 50000; i++) {
    printf("zzzzz\n");
}

[floooh]

Hmm, good information. Still weird though because there's nothing special about the init callback, it's just called in the first frame before the frame callback. All application- and window-system setup has already happened at that time.

I also checked GLFW, and sokol_app.h is already doing the same things (but I remember that I had this sort of problem before adding the "ActivationPolicy" setting. It basically comes down to these 3 things:

sokol/sokol_app.h

Lines 3831 to 3833 in 1b9b047

	NSApp.activationPolicy = NSApplicationActivationPolicyRegular;
	[NSApp activateIgnoringOtherApps:YES];
	[_sapp.macos.window makeKeyAndOrderFront:nil];

[floooh]

Apparently fixed via #982, although I was unable to reproduce the original issue on my M1 Mac with macOS 14.3 even without the fix (e.g. Apple might have fixed it too?).