#import

// this should be called from the application delegate’s applicationDidFinishLaunching
// method or from some controller object’s awakeFromNib method
if (![[NSUserDefaults standardUserDefaults] boolForKey:@”LaunchAsAgentApp”]) {
ProcessSerialNumber psn = { 0, kCurrentProcess };
// display dock icon
TransformProcessType(&psn, kProcessTransformToForegroundApplication);
// enable menu bar
SetSystemUIMode(kUIModeNormal, 0);
// switch to Dock.app
[[NSWorkspace sharedWorkspace] launchAppWithBundleIdentifier:@”com.apple.dock” options:NSWorkspaceLaunchDefault additionalEventParamDescriptor:nil launchIdentifier:nil];
// switch back
[[NSApplication sharedApplication] activateIgnoringOtherApps:TRUE];
}

As far as I can tell, beyond the code’s ugliness its only shortcoming is that it might produce a strange result for users who have disabled the Dock application and use other window management programs like Desktop Manager. Sounds like a small price to pay, though, considering the problems with the other approaches you describe in the article.

defaults write /Applications/Pukka.app/Contents/Info LSUIElement 1

If you were to then want to go back to dock mode, you’d use this:

defaults write /Applications/Pukka.app/Contents/Info LSUIElement 0

i.e., the same thing but with a zero instead of a one.

This is the method mentioned above of altering the app bundle itself, which is the method that some apps use to go dockless, but the one that will eventually mess with code signing.

So once you figure out how to go dockless, I’ll buy the app! There are so many dockless apps out there. I understand from your post that the issue isn’t as straightforward as you would wish, but don’t stop me from going dockless now because in the future Apple might change something… Or because of Applescript. I’d like to use Pukka in two ways: a) from netnewswire, b) as a bookmarklet. I’m sure 95% of your users do the same. Save us all from tearing our hair out Please!

I’m pretty open in how I target the binary. I should mention that it’s kind of unpredictable as to which version gets opened, though — it’s not always the outer one. It’s kind of up to the whim of Launch Services. Regardless, though, the launched version can figure out which one it is and launch the other. I’m currently using NSTask to launch the binary directly, but I could use NSWorkspace, /usr/bin/open, execve(), etc. Regardless, I’m still not seeing how to get the context of the current Apple Event to pass it along. For file opening and the NNW posting protocol, I have methods that are called, so that’s been easy, but for AppleScript, either my NSScriptHandler subclass’s performDefaultImplementation is called (for commands) or my app delegate’s application:delegateHandlesKey: is consulted (for getters/setters) but I’m not able to grasp the event to pass it along. Even if I could, I’ve tried passing dummy events and the Script Editor running the script seems to get confused and loses the connection with the app when the other version is launched.

The question of Apple Events, etc, probably depends on how you launch the hidden pseudo-app bundle. Higher-level approaches like telling NSWorkspace to open it probably mean you need to pass everything on yourself. A lower-level approach like execve(), targeting the binary directly, might mean you could just wait until after execve() to read all that information, and it’d all just arrive. This is an untested idea, though.