Ad-hoc deployment of DrawKit¶

DrawKit may find a good home in many applications that are not complete drawing applications. For example you might just have a dialog that pops up and allows you to define some quick graphic that you can use elsewhere. DrawKit is a good basis for these types of editors - you may not be using much of its power but it doesn’t greatly add to your application’s waistline or complexity, while still offering a lot of features “for free” if you want them.

Deploying DrawKit is basically always the same process - create a DKDrawing, a DKDrawingView or some other interface, and bind them together with a DKViewController or subclass. You can do this manually whenever and wherever you want.

There is another way however - you can let DKDrawingView do all the work. If a DKDrawingView is instantiated (from a nib, for example) and it gets as far as having its drawRect: method called with no drawing in place, it will create one, add a controller and stitch it all together. The view owns the drawing, in this case (the design of the controller prevents any awkward retain cycles). The drawing’s initial size is set to the view’s bounds, and is complete with a grid layer, a guide layer, and one drawable object layer ready to go. It has a tool controller set with the select/edit tool and works immediately. Of course you’ll probably want to tweak this setup, but at least the majority of the initial configuration is done. You can also override DKDrawingView‘s createAutoDrawing method to make the drawing differently, or modify the default one. This mechanism is intended to mirror the functional concept of NSTextView - you add the view and it creates a fully operational text editor. Likewise, DKDrawingView implements a fully operational drawing editor, just by adding the view.