Re: Running Cocoa from a dynamic library
Re: Running Cocoa from a dynamic library
- Subject: Re: Running Cocoa from a dynamic library
- From: Bill Appleton <email@hidden>
- Date: Sat, 30 Jul 2011 08:45:08 -0700
>> Sadly, Cocoa and many of the frameworks on which it is based really do
depend on the main thread and its run loop. Events have to be received
there and its run loop has to be serviced (run) on a regular basis.
this situation is basically the same on other platforms. the events come in
on some particular thread (the main one or whatever) and they must be
process & not blocked
we developed an architecture where the events come in on the main loop and
are passed off to another thread. the worker thread must run some things on
the main loop, but all in all the main loop remains free to run.
hope that helps.
On Sat, Jul 30, 2011 at 1:32 AM, Ken Thomases <email@hidden> wrote:
> On Jul 28, 2011, at 1:14 PM, Jens Alfke wrote:
>
> > On Jul 27, 2011, at 8:02 AM, Guido Sales Calvano wrote:
> >
> >> Ogre3D however, uses a cocoa window to render on, and obviously I want
> user
> >> input. But if I start ogre in a dynamic library ui events register
> incorrectly.
> >
> > It’s not the fact that it’s in a dynamic library that causes trouble (for
> example, all system frameworks are in dynamic libraries!) It’s the fact that
> you’re starting a generic Unix process (node.js server) and then trying to
> turn it into a GUI app by calling AppKit in it, without going through the
> usual AppKit initialization (NSApplicationMain). However, I don’t think
> calling NSApplicationMain is the right thing for you to do, because (a) it
> expects to be the first thing called when the process starts, and (b) it
> will take over the main thread.
> >
> > I know that this can be done, though I don’t know the details of how.
>
> You want to do a few things:
>
> * Read the class overview for NSApplication.
>
> * Invoke [SomeClass sharedApplication], where SomeClass is either
> NSApplication or a custom subclass of NSApplication. (It's what you would
> set for the NSPrincipalClass key in the Info.plist of a more traditional
> app.)
>
> * Call [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular].
> If you need to target 10.5 or earlier, use TransformProcessType() instead.
>
> * Load your main NIB, if you're using one.
>
> * Use the main thread to process events. Either invoke -[NSApplication
> run] or implement its equivalent. See Apple's GLUT sample code for an
> example of what sorts of things -run does.
>
> http://developer.apple.com/library/mac/#samplecode/glut/Listings/GLUTApplication_m.html
>
> Depending on the design of the host program into which you're loading
> Cocoa, you may need to invert the work of -run so that it's suitable for
> being called regularly, processing pending events, and then returning to let
> the host do its work.
>
> Sadly, Cocoa and many of the frameworks on which it is based really do
> depend on the main thread and its run loop. Events have to be received
> there and its run loop has to be serviced (run) on a regular basis.
>
> Regards,
> Ken
>
> _______________________________________________
>
> 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
>
_______________________________________________
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