site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=8AOX8uFVz7asOMgxyTK9Y3eQ8vmSRbT2FP6QF54xR2w=; b=I5cmv/kakUFcZs02NLidXoFPobtkiTLHLFdmwFUfBhgnImfjmUPt1rs9HjTIp8IWC4 tEEal9i2NH1wgGi2u/ysPn1DbKx0edaXToJtSxUVCF69obcPU0U9D+pyQ4N6hEq1IEXX IxmPBgLrGgkk7sGk5G6ykOJ81SwQdQRb+sQOY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Wx7VIUUPPNVRm68w21MT/2qiO7cU4gIIJbaziNgQZVS+V2YI8g9ESaF5zU+o0hpmrc 9MugK+rIjL5AW8BHbZh/6RKwMcOFK7H69M4BPvxFKYsF4D6p9FdbPSEs87wUKKjp1RIB 4ZY5BccjILxXSE6nnaMqBdbvD4/micSYjbJ+Y= On Jan 14, 2009, at 12:22 , Rakesh Singhal wrote: I have to read it completely but I would like to let you know that if I use LaunchAgents then my GUI is getting launch through daemon application. BUt I want to keep the daemon in LaunchDaemons and then I want to launch my GUI using daemon. Anyway, I hope this helps you. Jason _______________________________________________ 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... If this is what you want, you have to design it for this. Don't try and make your daemon launch a GUI. Instead, design two parts, the daemon and the GUI. Decide how you want them to communicate. You can use distributed objects in Cocoa, you could use a UD socket, you could use an IP socket... the choice is yours. Create the daemon and install it in /Library/LaunchDaemons. Have it listen using whatever mechanism you decide on (UD socket, DO, heck, mach port even), then install the GUI part in your user's LaunchAgents section. When the user logs on, the GUI will be launched by launchd and can then connect to the daemon and let it know that it just came up/get further instructions/whatever. That said, you should probably have a very good reason for doing this. Generally, when I create a daemon for some service and I want to have a GUI to interact with it, I /always/ let the user decide when to start and stop that GUI. For instance, I have written a daemon that controls a mail service. It comes up in the root namespace and is installed under /Library/LaunchDaemons/. It listens for management information on a UD socket. It uses the security framework to ensure that any user has been granted the system.privilege.admin right before it will respond at all. I then have a system panel plugin that does basic configuration. The system panel connects over the UD socket and provides information like whether the services is started/stopped... provides a button to recycle/stop/start the service and provides basic configuration information (start at launch, IP bindings, etc.). Finally there is a full GUI application. This GUI can do everything that the system panel can do, plus it will do real-time monitoring, allow performance tweaks and adjustments, and do a number of other things that don't make sense in the context of the system panel plugin. The GUI also communicates over the same UD socket. Using this design, I could easily create a text-only interface, a web interface, or any other number of interfaces. If I felt there was a need for remote configuration (right now there's a requirement /against/ that), I could add an IP socket as well (of course, this would then require some kind of distributed authorization to be added, but I digress). Basically, Rakesh, you have to look at your problem, look at the constraints, and look at the users and come up with a viable solution... then start coding. That is just as important as writing code. In this case, Mac users generally don't want all kinds of stupid GUI applications popping up when they start their computer. That is more of a Windows thing... and most Windows users I know hate this as well (they just accept it more readily because before NT 3.51 there really was no service mechanism for applications to use)... and of course, since NT 3.51 many programmers have been too lazy to write proper services so the design anti-pattern continues (although, to be fair, this is changing). If you have some background process that needs to run in the context of a user, however, from the time they log in, you could still use this approach. You write the daemon and use a UD socket for communication. You then write a background-only LaunchAgent that does whatever it needs to do and (for simplicity) maybe exposes a couple of DOs. Then the control panel and/or full GUI could interact with the LaunchAgent instead of with the daemon directly. This still lets you do any per-user background processing that you might want to do AND lets the user decide whether she wants to launch a GUI process. This email sent to site_archiver@lists.apple.com