Re: Non-AppKit equivalent for NSWorkspace and/or future-proof poseAsClass?
Re: Non-AppKit equivalent for NSWorkspace and/or future-proof poseAsClass?
- Subject: Re: Non-AppKit equivalent for NSWorkspace and/or future-proof poseAsClass?
- From: Phill Kelley <email@hidden>
- Date: Thu, 10 Jan 2008 21:01:48 +1100
>Il giorno 09/gen/08, alle ore 13:59, Phill Kelley ha scritto:
>
>> I'm trying to write an application in two parts: a client GUI and a
>> faceless "agent" (launched by launchd), communicating via Distributed
>> Objects. This all works.
>
>You *are* using LimitLoadToSessionType = "Aqua" and requiring 10.5+,
>riiiiight?
No. I want this to be Tiger-compatible (at least for the next 12-24 months).
In any event, I don't actually *want* GUI services in the agent so, of the
permitted values listed in tn2083 for LimitLoadToSessionType, "Background"
would seem more appropriate.
The idea is that there is one instance of the agent running for each user
logged into the machine. Apart from anything else, this strategy avoids
having to worry about security issues or having to maintain so-called
Chinese Walls between users, such as might arise if the agent was made a
daemon instead.
Each user *may* launch the foreground GUI to configure/inspect what the
background agent is doing but the GUI itself does not need to be running
for the agent to be able to do its thing.
>LaunchAgents may be launched at inappropriate times before 10.5 (that
>is, in sessions where a window manager connection can't be retrieved
>-- which makes more or less all of AppKit unusable). See Apple's
>Daemonomicon at <http://developer.apple.com/technotes/tn2005/
>tn2083.html> for more.
Thanks. I recall reading the earlier version of that tech note but the
current version goes a long way towards explaining the intermittent nature
of the launchd-associated launch-and-crash loop.
The main reason I had focused on /Library/LaunchAgents as the mechanism for
launching the agent was the neat way it deals with restarting in the event
of a crash; something a login item doesn't get me for free. Naturally, I
always hope to write crash-proof code but...
Now I need to mull over the wisdom of this in a pre-Leopard environment.
At 07:20 -0600 9/1/08, Jeff Johnson wrote:
>> 2. Does anyone happen to know if there is an equivalent for the
>> poseAsClass
>> mechanism (or can suggest an alternative approach that will keep
>> AppKit
>> happy)?
>>
>
>Yes, take a look at my article at <http://lapcatsoftware.com/blog/
>2007/11/25/working-without-a-nib-part-6-working-without-a-xib/>.
Brilliant! Ditto Jean-Daniel for pointing me at the MethodReplacement code.
Thanks also to Matt, Sean & Ricky for the sub-thread suggesting Carbon as a
workaround. I am always slightly wary of Carbon. I worked hard to remove
all Carbon dependencies from my code so reintroducing it seems like a
retrograde step. I realise that sounds like I'm sticking my fingers in my
ears and refusing to consider a perfectly rational suggestion so I'll give
it some more thought.
Regards & thanks, PK
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden