DrawKit Beta 7 (released May 1st, 2010) 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.
Note that as of from Beta 5, DrawKit is released under a standard BSD license, and is free for all use, including commercial. Note however, that there are still optional parts that are under alternative 3rd-party licensing and users of DrawKit will need to be aware of this.
In response to calls for a simpler demo application to help get oriented to Drawkit, I have created the following project. This is a non-document based application that provides a "bare bones" interface to DrawKit. It may help you get started. Note that the application includes DrawKit as an embedded framework, which is why it appears fairly large. But it will run even if you have not downloaded any other DrawKit resources. To compile from source you also need to download the DrawKit framework Xcode project above. To avoid problems compiling, ensure that both projects' main folders end up at the same level within some folder (e.g. "Projects") on your system. Last updated: May 1st, 2010.
The larger 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.
There is a mailing list for DrawKit which is starting to grow and is the best way to ask for help especially while the documentation isn't ready. To join, please click here.
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! Also, please be assured that documentation is being prepared, it's just always a lower priority than the code itself. Some preliminary documentation can be found here (PDF)
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 a coding style different from a lot of 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.
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 - only a preliminary document is available at present, with much more needed.
Is it perfect? No. Is it useful? I hope so. I hope it's what you might call "good enough to criticise".
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 5, January 2009)
(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 ;-)
© 2006-2008 Graham Cox