GNOME Bugzilla – Bug 745931
GTK application window opens behind console that launched it
Last modified: 2015-09-19 20:52:08 UTC
When I launch my GTK+ application from the Terminal on OS X it opens behind the Terminal. Expected behavior is for the window to open in front of all existing windows. This does not occur on Windows despite using the same GTK+ version (3.14.9) and dependencies.
Created attachment 308505 [details] [review] Proof of concept to force-activate the app. The underlying problem is that when you launch a program it doesn't automatically get focus until you switch to it by clicking in it in the UI. This is generally true in OS X; the exception is if you open an application in Finder and *don't* activate something else while the app loads then the app will have focus once it starts its run loop. This patch uses [NSApplication activateRegardlessOfOthers:YES] to force focus to the application at startup. This overrides the default behavior and makes it the focused app. It will do so even when the application is bundled and launched from Finder; that could be finessed by testing for a bundle first. I haven't tested to see if this creates conflicts with GtkosxApplication or GApplication: It may well do so. That might also be finessed in some cases by testing for the presence of a bundle.
Why would we want GTK+ applications to behave differently from what is "generallyt true in OS X" ?
(In reply to Matthias Clasen from comment #2) > Why would we want GTK+ applications to behave differently from what is > "generallyt true in OS X" ? I don't think we do when launching an application bundle from Finder. But Mac users launching applications from a terminal command line are rare enough that Apple probably didn't take their preferences into account when designing the system's behavior, and I suspect that those users would prefer that the launch-time behavior is closer to other Unixes. We know that at least one does. We could also transfer the decision to application developers: Those two lines can be called from anywhere in a program's startup; the only requirement is that the file that holds them has to be compiled with -x objective-c.
Hmmm, I tried opening a native application from Terminal and it also opens behind the Terminal window: /Applications/Calculator.app/Contents/MacOS/Calculator This is surely not what the user wants but it appears to be a flaw in OS X itself. On the other hand if I open gvim (from the third party MacVim app) from Terminal it opens in front of the Terminal window.
John, maybe your proof-of-concept could be put inside an API that the application developer can call from standard C?
(In reply to draymond from comment #4) > Hmmm, I tried opening a native application from Terminal and it also opens > behind the Terminal window: That's what I meant when I said that it's the general behavior. > This is surely not what the user wants but it appears to be a flaw in OS X > itself. I think "design decision" is more correct. Whether it's what most users want, I can't say. I don't really care, you obviously do. > On the other hand if I open gvim (from the third party MacVim app) > from Terminal it opens in front of the Terminal window. So they're presumably calling activateRegardlessOfOthers: YES. (In reply to draymond from comment #5) > John, maybe your proof-of-concept could be put inside an API that the > application developer can call from standard C? I could, but it would have to be in GtkosxApplication. We wouldn't want OS-specific API in Gtk+. OTOH, it's two lines. It can be one line: [[NSApplication sharedApplication] activateRegardlessOfOthers: YES]; That's hardly worth wrapping anywhere. An app dev can just include it inside an #ifdef and put foo_CFLAGS += -xobjective-c inside a Makefile.am if block.