> you [Jens] are right about all of that except we also run in "stand alone" > application mode, and we also have floating palettes and scripting windows > (etc) in developer mode in the browser
I would think, then, that mastering the anatomy of a standard Cocoa application would be well worthwhile. You might want to re-do your palettes and suchlike as nibs, for example, and at the very least you should know how to do this, otherwise how can you make an informed decision on which is the right approach? A 'Cocoa Testbench' app will also let you experiment with event handling in an NSWindow - presumably events will turn up through in the normal way through your NSWindow's sendEvent: method under NSAPI so you can take a look at that. But NSWindows are simple beasts. You will need to learn all about NSViews and the rich set of subclasses (like NSButton) that constitute the Aqua 'widget set'. These are right at the heart of the way a Cocoa app interacts with the user and it's unlikely that you will be able to (or indeed want to) avoid them. Presumably, your existing code has a way to layout widgets in a window and some kind of platform-independent event model. Once you know enough about how Cocoa works, you might be able to constuct your window layouts on the fly from whatever code or data structures currently build your UI, and you might be able to feed Cocoa events (e.g. a button press, to pick a very simple example) back through your existing event model. That's essentially what I do - I build the NSView hierarchy for a window from a Windows .res file and I have a reasonably convincing facsimile of the Windows messaging model to handle events. But then I graduated from the school of the terminally weird. It works though, although as I say it took a while to put it all together, and I now have common code across the two platforms with a reasonably native look-and-feel, which is what I wanted. Tough luck about Linux, but then that's not important to me. Looks like you have an interesting journey ahead of you. Paul Sanders. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
