Hi, I have written a small application which is a LaunchAgent and works fine on Leopard 10.5.x with the command launchctl load /Library/LaunchAgents/com.myname.myapp.plist. However on Tiger 10.4.11, since i know that launchAgents would not work accordingly i made my app as a loginItem by adding the path for my application in the loginwindow.plist. But the problem i am facing here is as soon as i install, my app would not launch immediately !( As on leopard 10.5.x ) . I have to logout and login again for application to launch, which i want to avoid. Can i in my postflight of the installer manually launch my application ?? what i mean by this is that ... in my postflight i would use "open <path to my application>" . This would no doubt launch my app , but i wanted to know if this is a good way of overcoming the problem?? what are its implications ?? thanks , Arjun
At 12:18 +0530 29/5/09, Arjun SM wrote:
what i mean by this is that ... in my postflight i would use "open <path to my application>" . This would no doubt launch my app , but i wanted to know if this is a good way of overcoming the problem?? what are its implications ??
That's a perfectly reasonable approach. There are two major gotchas, both of which also affect the launchd agent case: o privileges -- If you're installer runs with privileges, you have to make sure you switch to the user ID of the user running the installer before launching the agent. In the launchd case, failing to do this will launch the agent in the global launchd, and no good can come of that. In the login item case, failing to do this will launch the application as root, which is also not good. o remote install -- Neither approach will work in the remote install case. Most admins do remote installs over SSH, which means that the installer is running in a non-GUI context. Trying to start a launchd agent or a login item in that context will end badly. You will need to detect that case and not start the agent/login item. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
participants (2)
-
Arjun SM
-
Quinn