site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com On Sep 25, 2008, at 3:20 PM, Mario Emmenlauer wrote: launchd.plist(5) actually makes no statements on the launch.h API :- ( The API seems quite undocumented. From your answer I deduce that one can not set up or change launchd.plist's dynamically through launch.h API calls. Yes, the API is undocumented. But you can use it to set up a dynamic job. (The launchd.plist(5) is merely a persistent representation of the job data structure, not the job data structure itself.) This will not get you what you want with respect to launching GUI apps, however. I would strongly suggest creating an agent that runs for every user, is limited to the Aqua session, listens for events and launches the appropriate application using the appropriate high- level APIs found in the LaunchServices or AppKit frameworks. It sounds like good advice, but you're leaving me half way. My situation is that of a server environment with many users and almost no GUI login. You are right, a per-user pre-login launchd agent would be a solution, but it would also come with several drawbacks: 1) a 'manager-daemon' is needed anyways, for centralized network I/O Sure, but you can have each agent, upon startup, register with the manager. 2) pre-login Agents are only available since Mac OS 10.5, while many of our users have not yet upgraded Why would you need a pre-login agent? Again, that wouldn't do what you want. It'll display UI, but that UI would not be hooked up to the user's window server session. 3) One agent per user can be a lot, in large server environments. Leaving them running is too much, and starting them up via launchd is a lot slower than the fork/exec or posix_spawn. Starting these jobs via posix_spawn(2) from a daemon running under the system launchd will not do what you want, especially in the case of GUI apps. In fact, it'll simply fail to launchd GUI apps. You *could* submit a job to the system launchd with the UserName key set, but that will spawn the job under the system bootstrap, not the user's and not hook you up to any of the user services you might be expecting. The short of it is that there's no good way to launch a GUI app from outside a user session. You could pull off what you want to do for simple, command-line utilities -- though you could easily run into problems with some of our APIs. If it's any consolation, I'm not very happy with that state of affairs either. :) -- Damien Sorresso BSD Engineering Apple Inc. dsorresso@apple.com 408.974.7488 smime.p7s