It’s been sitting in my ~/Projects folder for the better part of a year, but now it really is about time I dust it off and set it free… finished or not.
It started with my work on LaserLine. I had written a parser for ILDA files, but needed a way to test its output. Naturally, I couldn’t accept Aqua’s presence in an app associated with an app for Lasers – which are all about bright lights and dark rooms. Granted, it was only two controls and some custom images, but by the time I was done there was no doubt in my or anybody else’s mind that the final app would be “dark”.
Knowing that a complete app would need a more complete library of widgets and subclassing AppKit seemed like a good way to get intimately acquainted with its internals, I didn’t stop there. A full accounting of my adventures in AppKit really deserves its own (lengthy) post that I’ll for later, I will just say this — kids, don’t try this at home. Even I, in my pixel perfecting, eye candy licking, gradient loving glory, will admit that the whole endeavor was likely not worth the time and frustration involved. But the work was done, so I might as well publish it.
Disclaimer: DarkKit is full of sketchy code. It began as a hack – and it still is a hack. It does a whole lot of things AppKit doesn’t want you do to; a whole lot of things you shouldn’t do. It uses private, undocumented methods and even shadier things (IIRC there was toying with a super’s instance variables somewhere). Keep this in mind if you think you might need help from AppKit folks – I doubt abusing their framework will endear them to you. Use at your own risk.
What does it cover? not everything, but hopefully enough to be kinda useful. Most of the controls have their dark alternatives and DKButton covers some of the button variants present in AppKit (the normal shiny capsule button, the square beveled button, and square gradient button). Where things get iffy are Views… NSScrollViews were not designed with alternative looks in mind (not that that’s a bad thing) and that causes problems when it comes to TableViews, etc.
Using DarkKit
If you’ve ever gone about working out in the dark, then you probably have a good appreciation for one of the reasons I decided DarkKit would be a nice thing to have. When everything around you is pitch black, the fluorescent glow of the computer’s screen stresses your eyes terribly, so much so that when I’d be typesetting text or some other project that extended way into the night I would regularly enable high-contrast mode (⌃⌥⌘8) to give my eyes a chance to relax. So, if you happen to be designing an application that is going to be used in low-light settings (a laser show for example) a good low-light interface approaches the point of being a requirement.
IMHO, a really dark interface also does an excellent job of placing content front-and-center. The huge contrast between your app’s monochrome controls and your app’s colorful/interesting content tells your eyes exactly what to look at and drastically reduces visual clutter.
So yea, if you happen to be doing a pro-thing (and you accept the disclaimer from earlier) DarkKit might be for you. And, if you hadn’t noticed yet, jet black interfaces seem to have a way of kicking an app’s sex appeal up a notch. So, if on the other hand you find yourself looking for cheap UI pixie dust DarkKit might also be helpful – not that I endorse pixie dust… just sayin’.
Seeing that doing something as damaging to you application’s stability, maintainability, and general code-quality as adding an illegitimate framework like DarkKit should only be done with the greatest care and after considered thought, I built a IBPlugin* so you can build all your dark interfaces with minimal effort right from interface builder. Enjoy!
*There was also a palette, back when that was cool…
» Continue on to svn.oofn.net
Hooray, my final semester has already arrived and is on its way out. With ~8 weeks of class remaining, I’m closer than ever to leaving university and being out in the job market.
