On Oct 9, 2010, at 1:22 AM, Jason Slack-Moehrle wrote: > I need to integrate Carbon and Cocoa so that I can replace the existing > Carbon GUI elements with Cocoa equivalents. Mostly Dialog Boxes, etc. > > I know that I need to write C-ACllable Wrapper Functions for the Cocoa stuff > that I need, but I am not sure how to identify what I need to do. > > Example. I know that I will probably need to use NSOpenPanel and NSSavePanel. > So I need to write a C-Callable Wrapper for the parts of NSSavePanel that I > would use? Like: setTitle, setMessage, etc, etc?
So far, my experience porting Carbon apps to a Cocoa UI has been that this is not a good general approach. It works for Nav Services and StandardAlerts, but for the general UI, I'd recommend you take a different route: Tear the head off your Carbon application. I.e. go into the code, and take out all the UI code, replacing it with calls that just provide lower-level data types like CoreFoundation collection types, std::vectors, C arrays or whatever makes sense in your case. Think as if you were developing a command-line-tool to do what your app does. What actual functions does it need? Or a shared library (Framework,dylib,DLL) that someone else could use to integrate your app's functionality into theirs. Then create Cocoa UI classes in Objective C that are essentially just clients of this library. In the terms of the GoF design patterns book: You delete the "view" layer from your Carbon application and only keep the "model" and the model-facing "controller" layer. Of course, you don't do this all at once, but rather go to one window, rip off its head, bolt on a new one etc. But be aware that you can't really ship any of the intermediate steps. While you can have a hybrid Cocoa/Carbon application to a certain degree, there's a wide uncanny valley between the two. You can have a Carbon application with modal dialogs written in Cocoa, and the standard edit menu items will work. You can have an HICocoaView in a Carbon application to have a few new Cocoa views in a Carbon window. But HICocoaViews go "dead" in a Cocoa application, and non-modal Cocoa windows in a Carbon app quickly run into window-layering issues where a Carbon window is in front of the currently focused Cocoa window etc. Ideally, you'd replace your menu bar and main event loop with the standard Cocoa one (NSApplicationMain & a xib) and just ignore all the broken windows for a while and move one over after the other. If you have a C++ application framework like TCL or PowerPlant, you might get away with replacing the framework-specific menu classes etc. with ones that wrap Cocoa objects (their menu item validation is much more like Cocoa's than what they did in "modern" Carbon). But try to keep the application launch sequence and as much of the UI the way the Cocoa application template does it. Particularly, don't try to launch the app without a NIB. It's more hassle than it's worth. You also might find a few useful bits of information in this article, though it's strictly written for people coming from the PC: http://zathras.de/porting-to-the-mac.htm PS - Of course, if you have CoreGraphics code, you can just take that along. See [NSGraphicsContext currentPort] and [NSGraphicsContext graphicsContextWithGraphicsPort:flipped:]. If you still have Quickdraw code with GWorlds, NSImage is your friend. If you have QuickTime movie code, ignore NSMovieView etc. and go straight to QTKit. For GraphicsImporters etc. look at CG, NSImage and ImageIO. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
