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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
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:
http://lists.apple.com/mailman/options/cocoa-dev/alberto_ricart%
40hotmail.com
This email sent to email@hidden
