Sat 12 Sep 2009 08:17:29 AM UTC, comment #2:
No, you can't do that. It's totally up to the app what happens when -NXAutoLaunch YES (not -autolaunch) is passed (the lib doesn't even understand it).
The library cannot make this kind of decision, because any and all special actions performed by an application when auto-launched are unique to that app.
On NS/OS, many apps have special behavior when autolaunched: chiefly Preferences, Mail, Terminal, and Edit.
Preferences defers creating its windows and doesn't load its nibs; all it does is start the clock view. Mail does the same (unless you disable the "Hide on Autolaunch" option), except it displays mail status in its icon.
Edit and Terminal use auto-launching as an opportunity to preload their code and set up their services, so when you click on their icons they start up fast (unless, again, you disable the "Hide on Autolaunch" option, in which case they start normally).
All act as reduced-capability versions of themselves. Preferences happens to not have an option for it, as its most-used function is as a combination calendar/clock.
For an app that has decided to treat autolaunching as preloading, the canonical response is for the application to send the shared NSApplication object the -hide: message in -applicationWillFinishLaunching. This prevents any application window from ever reaching the screen, because the Application Kit does not hide and unhide apps behind the scenes.
The point here is not that -NXAutoLaunch doesn't work, but that an app cannot start without putting any windows on the screen unless you bypass their creation entirely.
|