Application "BookMacster" menu does not show immediately

[jerrykrinock]

When I launch my app BookMacster with Alfred, its menu does not show until I activate a different application, then activate BookMacster, for example with the ⌘-tab application switcher.  According to users, this behavior started with Mavericks.

 

BookMacster has a preference option to launch in the background.  This is implemented by entering LSUIElement into Info.plist, and using TransformProcessType() after launching.  Due to a longstanding bug in Mac OS X, this needs to be done in a different place in 10.9 vs. earlier OS X versions.  All of the technical details are here.

 

Nonetheless, it works, in 10.9, for every launch method I can find, with the exception of Alfred.

 

PASS  Doubleclick in Finder
PASS  Put in Dock and click 
PASS  AppleScript "Launch Application”
PASS  Launch using the open(1) command in Terminal.app
PASS  Launch using -[NSWorkspace launchApplicationAtURL:options:configuration:error:]
PASS  Launch using the -[NSWorkspace launchApplication:]
PASS  Launch using the LaunchBar app launcher
FAIL  Launch using the Alfred app launcher

 

Maybe we need to work together on this offline.  I was thinking maybe BookMacster could detect when it was launched by Alfred and do TransformProcessType() the old way, but the parent process of apps launched by Alfred seems to be launchd, like apps launched by Finder, so I don't know how to determine when I'm launched by Alfred.

 

​Thanks,

 

Jerry Krinock

 

[Andrew]

When I launch my app BookMacster with Alfred, its menu does not show until I activate a different application, then activate BookMacster, for example with the ⌘-tab application switcher.  According to users, this behavior started with Mavericks.

 

BookMacster has a preference option to launch in the background.  This is implemented by entering LSUIElement into Info.plist, and using TransformProcessType() after launching.  Due to a longstanding bug in Mac OS X, this needs to be done in a different place in 10.9 vs. earlier OS X versions.  All of the technical details are here.

 

Nonetheless, it works, in 10.9, for every launch method I can find, with the exception of Alfred.

 

PASS  Doubleclick in Finder

PASS  Put in Dock and click 

PASS  AppleScript "Launch Application”

PASS  Launch using the open(1) command in Terminal.app

PASS  Launch using -[NSWorkspace launchApplicationAtURL:options:configuration:error:]

PASS  Launch using the -[NSWorkspace launchApplication:]

PASS  Launch using the LaunchBar app launcher

FAIL  Launch using the Alfred app launcher

 

Maybe we need to work together on this offline.  I was thinking maybe BookMacster could detect when it was launched by Alfred and do TransformProcessType() the old way, but the parent process of apps launched by Alfred seems to be launchd, like apps launched by Finder, so I don't know how to determine when I'm launched by Alfred.

 

​Thanks,

 

Jerry Krinock

 

This looks like the same issue, some reasoning, and a solution:

 

http://stackoverflow.com/questions/7596643/when-calling-transformprocesstype-the-app-menu-doesnt-show-up

 

Have you considered simply restarting your app after that option is selected instead of using TransformProcessType? This would allow you to go both ways too (background and non background).

 

Cheers,

Andrew

[jerrykrinock]

Thank you, Andrew.  I swear I have tried kludges just like the one reportedly recommended by Apple in that Stack Overflow article in the past, and none of them worked.  However, I am amazed to see that this Apple-recommended kludge actually works.  But I do not I like it because, if I launch BookMacster with this kluge from something other than Finder (Xcode, AppleScript, Terminal, or Alfred), the Finder's menu flashes momentarily before BookMacster's menu appears.  This happens even if I reduce the delays in the kludge from 0.1 seconds to 0.0 seconds.

 

Because this is not a top priority issue, I shall get back to you in a couple days, after I do more testing in more Mac OS X versions, and consider your other idea.

[Andrew]

Thank you, Andrew.  I swear I have tried kludges just like the one reportedly recommended by Apple in that Stack Overflow article in the past, and none of them worked.  However, I am amazed to see that this Apple-recommended kludge actually works.  But I do not I like it because, if I launch BookMacster with this kluge from something other than Finder (Xcode, AppleScript, Terminal, or Alfred), the Finder's menu flashes momentarily before BookMacster's menu appears.  This happens even if I reduce the delays in the kludge from 0.1 seconds to 0.0 seconds.

 

Because this is not a top priority issue, I shall get back to you in a couple days, after I do more testing in more Mac OS X versions, and consider your other idea.

 

If you set LSUIElement in the application's prefs plist, then you won't get that flash (this is what Alfred does), so if this is set, don't even transform the process after starting as it will be a ui element automatically.

[jerrykrinock]

If you set LSUIElement in the application's prefs plist, then you won't get that flash (this is what Alfred does), so if this is set, don't even transform the process after starting as it will be a ui element automatically.

I think you mean LSUIElement in Info.plist.

 

Anyhow, what you say is true, and I have set LSUIElement in BookMacster's Info.plist, and when I want it to launch in the background I do not transform the process and everything is fine.  The problem is when I want BookMacster to launch in the foreground.  That is when I transform it to foreground, and Finder flashes momentarily.  Of course, this is not noticeable when BookMacster is launched from Finder, as it usually is, so maybe this is acceptable, but I don't like it.

 

In case the above is confusing, I shall digress a little.  BookMacster has a  Launch in Background user preference.  Of course, by default it is off, because otherwise new users would never see the app.  It is in fact only available if the companion Show status in menu bar preference is enabled.  The users and use cases for Launch in Background are in the minority, but significant.

 

Now there are two mirror-image approaches to implementing a Launch in Background user preference.  The first approach is to set LSUIElement in Info.plist and, during launch, do nothing if the preference is background, or transform to foreground if the preference is foreground.  The second approach is to not set LSUIElement and, during launch, do nothing if the preference is foreground, transform if the preference is background.  

 

I use the first approach because transforming to background is not supported in Mac OS X 10.6. (*)  I think you're telling me that this first approach is also used in Alfred, but Alfred does not have a Launch in Background preference setting.  It's hard-wired to be an LSUIElement (background), and comes to the fore only when user clicks the gear.

 

* * *

 

While I'm thinking about this, I'm still curious, Andrew, about my original question - does Alfred use some tricky method for launching apps which is not in the list in my first post?  If not, that is, if Alfred uses, as I would, one of the conventional NSWorkspace methods, then maybe the significant factor is the fact that Alfred itself is a background app, and the stealth bug fix which Apple did in Mavericks only works if the "launching app" (I'm not sure what that means because the actual launching is apparently done by launchd) is itself in the foreground.  Note that, in contrast to Alfred, LaunchBar is a foreground app.  It appears in the dock, app switcher, has a menu, etc.

 

Thanks,

 

Jerry

 

(*) Yeah, I know, another reason to drop support for 10.6.

[Andrew]

While I'm thinking about this, I'm still curious, Andrew, about my original question - does Alfred use some tricky method for launching apps which is not in the list in my first post?

 

Alfred simply uses NSWorkspace's openFile, so I have to agree that this will be down to Alfred being a background app.

 

Alfred 2 doesn't actually ever come to the foreground, the preferences are a completely separate app which Alfred launches, allowing the core of Alfred to stay very lightweight indeed.

[jerrykrinock]

Thank you for the explanation, Andrew.

 

I'm not sure what I'm going to do.  I was hoping I could use the simple TransformProcessType(), and then somehow detect if it worked, and if not do that kludgey dance with Finder from the Stack Overflow thread which is supposedly recommended by Apple.  But alas, [NSMenu menuBarVisible], [[NSApp mainMenu] menuBarHeight] and [[NSApp mainMenu] size] all return values indicating that the menu is showing, even if the app is in LSUIElement state.  Arghhhh.

 

If I come up with anything useful, I'll post it to the blog post mentioned above or the Stack Overflow thread linked to by Andrew.

 

Thanks again for your help.