DrawKit - Cocoa Vector Graphics Framework

DrawKit Version 1.0 BETA 3 SDK - Download Source Code (1.9M .zip archive)

DrawKit Demo Application for BETA 3 - Download Source Code (3.2M .zip archive)

Executable Version 1.0 BETA 3 Demo/Test App - Download Universal Binary (1.6M .zip archive)

DrawKit Beta 3 is now available for download. Please read the release notes in the DK SDK for more information. For a general overview of the library and the rationale for it, please take a look here. Drawkit requires Mac OS X 10.4 or later and is Universal. To compile the source code requires Xcode 3.0 or later, and Mac OS X 10.5 (Leopard) or later.

The demo application remains a fairly full-featured application environment in which DK's features can be explored. For this release it has been polished and improved to make this easier and a better user experience, but bear in mind that this is not meant as a user-oriented drawing application - it is for programmers to explore what DK can do. In addition there is now a minimal project which builds a bare-bones application that links to DK. To build this you must first download and compile the DrawKit SDK. The bare-bones application uses automatic DK creation to demonstrate that a DK application actually doesn't need any code at all - just a suitable nib file. Because there is no UI to create new objects, you can get started by dragging images into the drawing area, or cutting and pasting from the main demo applicaiton.

Shortly a public read-only SVN repository will be available that will allow you to keep up with DrawKit updates as they happen, rather than wait for infrequent public beta drops. Watch this space!

What Rocks?

To be honest, I have no idea. I've been working in something of a vacuum on this, and I'm a self-taught (Hillegasse got me started!) Cocoa guy. So it might suck utterly. I don't think it does, but it's hard to be sure. I have been keeping a firm eye on other codebases out there, some of which are excellent, but hard to use, some of which are not very general, and others which I can only judge by the final apps built with them. I believe that Drawkit stands up to scrutiny against all of these on various levels, but on the other hand I make no claims about its suitability for purpose, etc. I built it primarily for me and some apps I plan to build.

One of the important things I have tried to keep in mind when creating DK is usability to a developer. Thus the classes should be easy to understand in principle and have many high-level methods that should do what they say they do in an obvious way. Right now the main documentation is the code itself, whch is liberally commented (but only to the degree of stating what things do, and pointing out anything non-obvious). Proper docs should follow along, but as always documentation is a lower priority than the code itself, and gets done as and when.

I will also say that I have an unusual coding style compared to most Cocoa code I've seen. I have one overriding reason for this - readibility. If you don't like it, sorry, but that's the way it is (and will always be - I have evolved this style over many years and it's code I like to read). Readability == maintainability as you know. I just love wasting whitespace, so you may as well get used to it. Text is edited using Xcode's default settings, with real tabs set at an indent of 4.

What Sucks?

Lots, I'm sure. This is a BETA quality download. It has the complete feature set I originally planned to include, but there may be obvious features I forgot (let me know, if sensible I'll add them). Some of the code could probably be better factored. In most places I use a straightforward approach and little trickery. Some of the design decisions may appear strange (possibly - again I really don't know for sure) but nearly all are made with good reason - flexibility, mostly. Performance is lacking in many areas, since there is no serious attempt at optimization beyond the very obvious. Error handling is fairly minimal. So, overall, this is genuinely a beta version - it's feature complete, but not final quality. The source itself is also in need of some organization as a whole, though each individual class should be reasonably straightforward and easy to figure out.

The demo application supplied in the download is the main "test harness" through which I have developed Drawkit, so it's a thoroughly tested application. However, it's not a finished quality application - its user interface is crude and thrown together, occasionally buggy, and not an example of the best way to present many of DK's features in a real-world app. On the plus side it simply allows you to access many of the features of DK without too much user-level interpretation that a real app would probably have to do, so it's actually quite powerful, once you get your head around how DK works. So please do not judge it as a drawing program - as such it's unlikely to win any awards - what's important is the underlying DK code and what you can do with it. The Demo/Test app is known to be quite buggy in places. The bugs are in the demo app's quick-and-dirty controllers mostly, and should not be reported as DK bugs.

Documentation - there really isn't any beyond the overview and the user guide to the Demo app.

Is it perfect? No. Is it useful? I hope so. I hope it's what you might call "good enough to criticise".

What next?

Assuming you think DK is worth something to you as a developer, the first thing I urge you to do is join the mailing list. I intend this to be the main channel for getting a DK community (however small it might turn out to be) off the ground. Bug reports, discussions, suggestions and asking for help can and should all be done primarily through this list. If it gets busy at some later stage we can worry about refactoring it then. I believe in discussing everything in a list so that everyone benefits from everyone else's issues. All discussions will be handled politely and with courtesy - if anyone remembers the MacZoop mailing list you'll know the kind of thing I'm aiming for. So please sign up!

The next step for more committed developers is to get access to the svn repository so you can get (and submit!) the latest fixes as they become available. While I will make available complete builds as new stable ones become available, for the serious developer, access to svn is a must. At this stage access to svn is on a request basis.

In DK terms itself, I'm hoping it will find lots of uses, so if you feel inspired to build an app around it, please let me know! The best way to flush out bugs is to really use it, and for most that will mean building an app around it. Performance problems will rear their heads fairly early on - plenty work needs to be done in this area.

GC, August 2007 (updated for Beta 2, April 2008)

(FYI: the graphics on this page were all drawn using the DK demo in about one minute (the .png files here are not representative of their actual quality in DK). That's one minute for all three. Of course the code behind it took months, but hey, that's leverage ;-)