Re: Agent Applications and launchd
Re: Agent Applications and launchd
- Subject: Re: Agent Applications and launchd
- From: Keith Alperin <email@hidden>
- Date: Mon, 2 Jan 2006 09:53:33 -0600
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:
This email sent to email@hidden