Re: Agent Applications and launchd
Re: Agent Applications and launchd
- Subject: Re: Agent Applications and launchd
- From: Alberto Ricart <email@hidden>
- Date: Tue, 3 Jan 2006 00:44:19 -0600
Keith,
Yes, this is exactly what I do. Essentially, my script looks
something like this (note the template was generated by the tool I
described in the previous post):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://
www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.xxxx.yyyyy.ZZZZ</string>
<key>OnDemand</key>
<false/>
<key>Program</key>
<string>%@</string>
<key>ProgramArguments</key>
<array>
<string>%@</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>ServiceDescription</key>
<string>something to tell the user where this came from.</string>
<key>UserName</key>
<string>root</string>
</dict>
</plist>
The %@'s gets replaced with the full path to the executable - note
there are two places where this is set. The value would be something
like:'/Library/PreferencePanes/My.prefPane/Contents/Resources/foo'.
Note I am assuming that in the MacOS folder you have the preference
panel executable.
Now, depending on how you want to run there are two places where you
can install the plist, one is /Library/LaunchDaemons the other is /
Library/LaunchAgents (you can also install in ~/Library/
LaunchAgents). There's a difference on what these locations do.
LauchDeamons makes your process run as root, which may NOT be what
you want. The other two I believe should run as the current user.
I am assuming that your pref pane will have some sort of checkbox
that requires authentication before the user can edit the UI, and
that editing that ui causes the launchd plist file to be created and
installed. The bumps to get this to work are not hard but requires
some understanding of the SecurityFramework because if you are
installing in the system domain, you won't have write access to those
directories unless you are running as root. The general geist is to
write a tool that performs the installation and startup chores
(calling 'launchctl load pathToYourPlist') and is separate of your
preference pane.
The steps for this are create an AuthorizationRef with the correct
right (system.privilege.admin). Call
AuthorizationExecuteWithPrivileges to start your tool. In your tools
code, verify that you were launched by the authorization mechanism
(otherwise you added a security hole) by checking the ref you
generated via AuthorizationCopyPrivilegedReference (simpler than
packing the authorization and sending it via a pipe). If you get a
ref and no errors, install your file and call the command to load
your daemon, otherwise exit.
For more info, checkout: <http://www.macgeekery.com/tips/
all_about_launchd_items_and_how_to_make_one_yourself>
Cheers,
/a
On Jan 2, 2006, at 9:53 AM, Keith Alperin wrote:
Oy! So we're back to the beginning. I'd like to use launchd, if
for no other reason than for the pedagogical value. My original
post was about how I couldn't figure out the command to use in my
launchd plist file. My executable is a faceless .app that resides
in the resources directory of a PreferencePane bundle. Has anyone
used launchd to launch an app like this?
Regarding the (very well thought out) trade offs listed below, I
can live with a 10.4 only situation. My current app uses some
accessibility features that are 10.4 only. For my next app which
will not, I'll have to make this decision again. As for the lack
of a UI to turn this on and off, that's basically what my app is: a
PreferencePane that will be used to configure/enable/disable this
agent; so i've got that covered. Finally, I completely agree that
(C) is a pretty awful solution. If it were provided as
LoginItemsAE.framework then I might feel a little better about it.
One thought I had while reviewing the LoginItemsAE sample was that
this might be accomplished via applescript? Does anyone know if
that's possible?
Thanks for the discussion, everyone!
Keith
ps. thanks to Joachim for sharing his code with me.
On Dec 31, 2005, at 1:01 PM, Alberto Ricart wrote:
Zero lines of code is absolutely the right count. I had gone
through the same path Jerry had gone through a few days back for
the various early iterations of my current project:
A) load and write loginwindow.plist directly (approx 10 lines)
B) cocoa-dev's CFPreference's code (trimmed and made reusable in
75 lines)
C) looking at Apples code for doing this (ugh - can you say bloat)
D) using launchd (22 lines on the plist, but given the 'Launchd
Editor' from MacGeekery <http://www.macgeekery.com/tips/
all_about_launchd_items_and_how_to_make_one_yourself> really only
4 values clicked on the app plus and about a 12 lines of code to
replace the location of exe when installed).
Indeed option 'D' tastes great and has few calories and zero
carbs. The only disclaimer is that it is 10.4 only. Luckily for
me, my app has both a client and server daemons, so launchd aligns
very well with my app, but the real deciding factor I had already
taken. My app uses Core Data, so I was already 10.4 only and
loving it.
Now, while this works for me - I don't think it is the right thing
for all apps. For one thing, there's no UI/Preference Pane to
manage LanchAgents/LaunchDaemons settings (whops, I guess I know
what is next on my plate), which is the way that users are
accustomed to turning these things on/off. Thus it is 'easy' for
developers to want to take this route, and run into this thread
again.
From my perspective (C) is an awful solution. It is not API, it is
just a bunch of apple events. So something seemingly simple as
"add this guy to my autolauch list" requires 800 lines of code.
Just to keep it in perspective, ALL my data management code
including utility code to populate transient data into my Core
Data application, register DO object that provides access to the
data to clients, etc is LESS than that, and that is the code that
matters to me most. Sure it is the 'supported way', but if you
include it in your code you have an additional 800 lines of code
to support just for that very tiny small feature. Realizing that
sample code from apple is just that, sample code (it illustrates
how to do something) there's too much fat and calories on that
choice. From my perspective it has zero guarantees on its
suitability to do anything, even if it looks official enough (if
you are not sure go read the 30 lines in the disclaimer).
Cheers,
/a
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40hotmail.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden