Design Philosophy¶

The design of DrawKit is very much driven by the classic 80/20 rule - its defaults and design decisions are intended to cover the 80% of typical uses with minimal set-up or configuration. If you find yourself in the other 20%, you’ll need to do a little more work, typically, and the more specialised your needs the more you’ll have to do. It’s inevitable that DrawKit cannot provide the perfect solution for all possible apps, even within the arena of vector drawing, since every programmer will have different needs.

One thing that is true of nearly every class, is that they will “just work” with little or no set-up. A high proportion of objects require a straightforward alloc + init to instantiate, with very few requiring complicated designated initializers. Most classes have convenient construction methods to further simplify instantiation for the majority. Of course, these objects may not “just work” how you want them to in this state, but at least they will generally do something useful, and any further set up you need to do is really a case of moving them away from their default states. The point of this is to give the user of DrawKit an easier time - instead of wondering if you have marshalled a whole lot of configuration parameters in just the right way to get a working object, you simply start with a working object and gradually adapt it to your needs. It should help give confidence in the framework and be much less error prone. Most development proceeds iteratively, so typically you’ll start with a working, but probably non-optimal object, and one step at a time change it to do what you want, testing each time or after each few changes. This way it’s much easier to pick up a problem than if you had to start with many tens of settings “up front” . This philosophy reaches its zenith with the complete automatic instantiation of an entire working system by a view if you don’t do it for it. It’s also typical of much of Cocoa itself.

While DrawKit has many classes that need to be assembled logically to build a working system, in general there’s not usually a strict order for doing things.

For example, you could add a layer to a drawing, then add objects to the layer - or build a layer complete with objects and add it to the drawing. It’s up to you. It’s a similar story when styles are assembled from collections of rasterizers - order of assembly isn’t too critical.