This article is more than 1 year old
Apple's ImageKit exposed
Mac Secrets When Leopard arrived, a number of significant new technologies came with it, including Objective-C 2.0, Core Animation, and ImageKit.
ImageKit brings together a number of classes designed to make it easy to display and edit images, view slideshows, take pictures using an attached or built-in camera, and more besides. In fact, ImageKit is itself built on top of Core Animation, hence the snazzy effects that it uses. The latest version of Preview also makes use of ImageKit when displaying and manipulating images.
This all sounds great and doubtless gets you straining at the leash to start working with the ImageKit classes, right? Unfortunately, there are some intriguing holes in the documentation. These piqued my interest.
The IKImageView class is designed (as the name suggests) to implement image viewing along with simple editing capabilities. It's easy to configure an instance of this class so that double-clicking the image view brings up a standard edit panel, from where the user can adjust things like gamma, saturation and brightness, as well as applying assorted Core Image filters.
Problems arise, though, when you start trying to really use IKImageView in anger, and - yes - anger could well be part of your experience. For example, the documentation states you can assign a delegate to IKImageView, but completely avoids telling you what delegate methods to respond to. Here's what you get:
An IKImageView object's delegate is inserted in the responder chain after the image view itself and is informed of various actions by the image view through delegation messages.
Helpful? There's no indication of what actions we're talking about, or what messages are sent to the delegate. In fairness to Apple, the lack of documentation is probably due - in part - to the complexity of the ImageKit framework.
If you've done much programming with Core Animation, you'll know that different layers sometimes field different messages. And in the same way, the architecture of ImageKit means it's not just the IKImageView class itself that gets to talk to the delegate object you supply.
So what delegate methods are available? The following methods are implemented directly by IKImageView.
- (void) selectionRectAdded: (IKImageView *) imageView; - (void) selectionRectRemoved: (IKImageView *) imageView; - (void) selectionRectChanged: (IKImageView *) imageView; - (void) imagePathChanged: (NSString *) imagePath;
As you'll infer, the first three delegate methods are triggered when the current selection rectangle changes: This implies you're using a relevant tool mode such as IKToolModeCrop or IKToolModeSelect. The fourth method is triggered whenever the image path changes such as - for example - when the user drags a new graphic onto the image view. This is useful because the full path is supplied as a parameter, but it's annoying that the relevant image view instance isn't returned.