I can tell you a bit about how we used Cocoa UI elements in the Magma Plug-in. When we created the project we wanted to target CS and CS2, so we had to do something that would work with Mach-O and CFM applications. This meant that our Cocoa code had to be in its own loadable executable bundle. We placed all the UI and most of the functionality in this separate code library.
The InDesign plugin adds a few menu items and a bit of standard plugin code and a bit of code to handle manipulating page items and linking to new images, but is mostly just a shell around this separate plug-in bundle. The bundle exports a C interface that is the bridge between InDesign and the Cocoa code in the bundle. The InDesign plugin loads the bundle when needed and then uses the C-interface to bring up the modal Cocoa UI.
One thing to consider is that you can use Carbon UI widgets with Interface Builder and nibs. You could use this technique to take advantage of Interface Builder, but you are still stuck with the Carbon world for handling events and the controller code.
You can also now fairly easily use Cocoa right in an InDesign plugin with no loading of a separate bundle, by following the instructions in Peter's link. Its mostly just making sure that you initialize the NSApplication runtime before you start running cocoa code and doing the right thing with NSAutorelease pools. Note that there are challenges at the fringes of handling events and you will have to of course glue all the Cocoa code to the InDesign model and other APIs as needed. Its quite a bit easier to do this in a modal dialog or even a mode-less floating Window. Of course the contrast in UI of having your own normal Mac OS palette mixed in with InDesign's regular Adobe palettes is not necessarily a good choice for users. I'm not yet convinced if this route saves you a lot of effort unless you are needing UI elements that are not in the standard InDesign widgets.
It may be possible to create an InDesign ControlView to host cocoa UI for use in a regular InDesign palette. This would be similar to how the CS4 applications are hosting Flash based UI in palettes. You could perhaps create this new ControlView so that was associated with a nib that it loaded and used for its children. You would probably have to have this control view go back up to its containing window and offset the views it loaded in the nib based on its current location in the window.
The trickiest part I think would be event handling. I just don't know enough about mixed Carbon/Cocoa event handling to predict what problems you might run into making sure mouse and key events do the proper thing in this situation.
-- Chris
6
Replies
AdChoices