Snow Leopard & LSUIElement -> application not activating properly, window not "active" despite being "key"

Question

Hi,

I'm running into a few problem with a background application that uses LSUIElement=1 to hide its dock item, menu bar and prevent it from appearing in the Command-Tab application switcher.

It seems to be a Snow Leopard only problem.

The application places an NSStatusItem in the menu bar and pops up a menu when clicked on. Selecting "Preferences..." should bring up an NSWindow with the preferences.

The first thing that doesn't seem to work is that the Window does not get ordered in at the front, but appears behind all other application windows.

I tried to fix this by calling

[[NSApplication sharedApplication] activateIgnoringOtherApps: YES]

but that didn't work.

After a while I figured out that the menu is blocking the message to the run loop from being sent, so I wrote another method on the MainController and sent the message with a delay:

[self performSelector:@selector(setFront:) withObject: [preferencesController window] afterDelay:1.0];

-(void)setFront: (id) theWindow {

 [[NSApplication sharedApplication]activateIgnoringOtherApps:YES];
 [theWindow orderFrontRegardless];
 [theWindow makeKeyWindow]; 
        [[NSApplication sharedApplication] activateIgnoringOtherApps:YES];
}

Note the send-every-possible-message-to-make-it-do-what-it-should-be-doing-approach.

This works, kind-of, the window is brought to the front on top of all other windows from all apps, BUT most of the time it isn't active, meaning it's title bar is greyed out. Clicking on the title bar won't make the window active either. Clicking INSIDE of the window will make it active!?

This all didn't seem to be a problem in Leopard; just calling activateIgnoringOtherApps and making the window key seemed to work just fine.

In Snow Leopard there is a new API designed to replace LSUIElement that is supposed to emulate its behaviour:

http://developer.apple.com/mac/library/releasenotes/cocoa/appkit.html

I've played around with that, but it's SL-only and I haven't been able to get LSUIElement being set.

Any help would be greatly appreciated!

Answer 1

After posting the question in desperation, I did continue looking and did eventually find the solution. Since this stumped me for a few days and there seems to be no other answer out there that google can find, I'll explain the solution for "future generations".

Snow Leopard adds a new NSApplication presentationOptions API:

http://developer.apple.com/mac/library/releasenotes/cocoa/appkit.html

This is supposed to simulate the way that LSUIElement works, but provide more developer control. Unfortunately, the simulation isn't perfect so there is a change of behaviour between 10.5 and 10.6.

In particular, if your application has the LSUIElement = 1 line in its info.plist, Snow Leopard will initialize "the application’s presentationOptions .. to an equivalent combination of NSApplicationPresentationOptions flags instead".

Only it doesn't really. It sets the new NSApplication setActivationPolicy to NSApplicationActivationPolicyAccessory:

"The application does not appear in the Dock and does not have a menu bar, but it may be activated programmatically or by clicking on one of its windows. This corresponds to value of the LSUIElement key in the application’s Info.plist being 1."

Despite the mention of being activated programatically, activateIgnoringOtherApps: is simply ignored completely.

The solution is to set the activation policy to "regular":

[[NSApplication sharedApplication] setActivationPolicy: NSApplicationActivationPolicyRegular];

Of course, you can only do this if you use the 10.6 SDK as Base SDK, something few people want to do at the moment, so below is a 10.5-safe way of doing this:

NSApplication* app = [NSApplication sharedApplication];

if( [app respondsToSelector: @selector(setActivationPolicy:)] ) {

    NSMethodSignature* method = [[app class] instanceMethodSignatureForSelector: @selector(setActivationPolicy:)];
    NSInvocation* invocation = [NSInvocation invocationWithMethodSignature: method];
    [invocation setTarget: app];
    [invocation setSelector: @selector(setActivationPolicy:)];
    NSInteger myNSApplicationActivationPolicyAccessory = 0;
    [invocation setArgument: &myNSApplicationActivationPolicyAccessory atIndex: 2];
    [invocation invoke];

}

I hope somebody will find this useful.

Answer 2

Thanks, Frank R. As it happens, I am making a background, status bar App, and noticed that clicking preferences, after opening the preference pane, doesn't bring the preferences window back to the front like I want it to. Very odd sense of deja vu as I read this. As you say, I will have to build with SDK10.5 for the final version of the App. My question is, in 10.5 the above fix doesn't do anything, right ? Do you have a fix that works for 10.5 ? Or, is it that if I were to run this App on a 10.5 machine, the problem would not occur in the first place.

Thanks for posting this, Colin