Interface Builder Palettes

Update: Opened for comments.
 
Interface Builder is a really useful tool for setting up moderately complex applications. However, as soon as you write a few views classes of your own, or a few classes whose objects can be configured beyond being connected to other objects, you usually find yourself writing lots of setXX: lines to perform configuration after loading your NIB. Wouldn't it be great if you could avoid this work?

That's where Interface Builder Palettes (or IBPalettes for short) come in. An IBPalette is a nice little plugin for Interface Builder that contains a couple of classes, images, sounds, and inspector panels for editing instances of your custom objects. While it may sound like a lot of work to write an editor plugin for your class, IBPalettes are like most of Cocoa: pretty straightforward.

That is, it would be very straightforward. In practice, there is next to no documentation on IBPalette & co. from Apple. Luckily Sun was on board the OpenSTEP train for a while, and so instead of Apple's docs, you can peruse Sun's documentation on Interface Builder. It's a little dated, and a few of the newer constants are MIA, while others are mentioned there that have long since been KIA, but at least it's a start.

There's also a nice article on Interface Builder Palettes at CocoaDevCentral that gives an example that is a little too simple, but at least nicely illustrates what classes are needed as a minimum.

To summarize, you create a new IBPalette project in xCode, which gets you an IBPalette subclass that basically returns the name of your NIB file containing the template objects to drag from IB's Palettes window.

Then you write initWithCoder: and encodeWithCoder: methods for your class so IB can save it to a file (This method will also be used during drag and drop, so if you suddenly find your drag image "tearing off and freezing" in the middle of dragging your item off the palette, it's most likely a bug in those two methods).

Finally, you customize the IBInspector subclass, which implements the edit fields for IB's Attributes pane in the inspector. Keep Console.app open while testing your palette: that's where your error messages will end up while your palette is running in IB.

Since not all classes are views, and some views may not look very recognizable on the palette, IB also lets you create another view to stand in as a placeholder on the palette. Typically you'll want to use an NSImageView containing a small screen shot or something like that. Call associateObject:ofType:withView: in your palette's finishInstantiate method to connect a template object of whatever type you want with that view. There are various constants for the type: IBViewPboardType if it's a placeholder image for another view, IBTableColumnPboardType for an NSCell subclass that can be used in an NSTableColumn etc.

If you want to have your view accept objects dragged onto it (e.g. like NSCells can be dragged onto an NSTableView's column headers), check out the InterfaceBuilder/IBViewResourceDragging.h header, particularly the IBViewResourceDraggingDelegates protocol and the category of same name on NSView. On actually extracting the received objects from the data, see Jay Tuley's website, where you can also get the IBObjectContainer.h header, which Apple apparently doesn't include.

So, you see, from a very simple palette that just edits properties of your views to complex ones that customize the tool tips displayed in the palette for your custom array class using toolTipForObject:, you can do quite a lot. As I figure out more details about this, I'll keep you posted in this location.

Reader Comments: (RSS Feed)

No comments yet

Or E-Mail Uli privately.