When I started development on MOO I knew I wanted the project to use Mike’s code but I also wanted to take advantage of Cocoa’s Garbage Collection and Snow Leopard’s blocks. I originally tried to retrofit MAKVONotificationCenter to work with GC and with blocks but it rapidly become a very difficult task. So I wrote my own KVO Notification class that was fully GC compatible and worked purely with blocks (no delegate methods at all).

Jumping as quickly into the code as I can, here is an example showing a KVO block that modifies a CoreAnimation layer’s position in responses to changes in the application’s model (example code adapted from MOO’s CGameMapView.m):

void *theBlock = ^(NSString *keyPath, CALayer *self, NSDictionary *change, id identifier)
    {
    self.position = CGPointMake(self.viewPoint.scale * self.modelObject.position.x, self.viewPoint.scale * self.modelObject.position.y);
    };

CALayer *theLayer = ...;
[theLayer addKVOBlock:theBlock forKeyPath:@"modelObject.position" options:0 identifier:@"KVO_IDENTIFIER_1"];
[theLayer addKVOBlock:theBlock forKeyPath:@"viewPoint.scale" options:0 identifier:@"KVO_IDENTIFIER_2"];

I find this, blocks based, style of KVO handling much cleaner and easier to both code and maintain. No worrying about selectors and targets and passing whatever data you need into the delegate method. You just declare your block and register it with the KVO Notification Center.

Clean-up (unregistration) is also straight-forward, although with Garbage Collection enabled applications this isn’t usually even necessary.

If you’re sharp-eyed you might notice that I’ve called one of the block parameters “self”. By providing my own ’self’ parameter I am obscuring and prevent access to the parent method’s ’self’ parameter. The reason I am doing this is because I’ve found it is very common to register for notifications for “self” and unless you’re very careful you can end up with a horrible retain cycle caused memory leak. By providing my own self parameter I obscure the parent method’s self and make sure these kind of retains cycles don’t happen.

The code is released under the BSD License on bitbucket (mercurial): http://bitbucket.org/schwa/kvoblocknotificationcenter/. You’ll obviously need use this on Snow Leopard or possibly with Landon Fuller’s plblocks toolchain (although I haven’t tried that myself).

(Update: I’ve posted a movie on flickr of KVO Block Observing in action) (update 2: Joachim Bengtsson has posted a great HOWTO guide for blocks. It also goes into some detail about the “self” problem I mentioned and a better solution (__block variables)

TouchMap.mov

with your vanilla NSImageView…

referring to an image file within an Xcode project…

Holy Cow! An Acorn file? Does that mean I can use Acorn files directly in Interface Builder 3? Does that mean you’ve written an NSCustomImageRep that understands the Acorn file format? Does that mean I can use Acorn files directly in my Cocoa projects? And that means I no longer have to keep exporting these bloody files as pngs so I can use them in Cocoa, right? Will this give rixstep some ammunition to go apeshit insane about?

Yes! Yes!! Yes!!! Yes!!!! Yes!!!!! Almost certainly.

Not only does Gus Mueller generously provide details about the Acorn file format, he has even released the source code to his Acorn Quicklook plugin. This gives me everything I need to convince NSImage to load Acorn files.

You might well be asking yourself why. I was getting annoyed with having to constantly keep exporting original Acorn images as pngs or TIFFs so I could use them in Xcode. I’m prototyping a new application that uses a lot of custom UI elements. These elements are made up of one or more pngs, some of which needed a lot of tweaking and attention to detail to get right. Acorn is perfect for UI work (although it needs more than 2000% zoom! cough) but having to export as png (or another format that Cocoa understands natively) and manage two sets of images (original Acorn, exported png) was turning into a pain.

I’ve taken Gus’ QuickLook code and wrapped a small NSCustomImageRep around it. Very small. I’ve repackaged it up as a Framework so you can refer to it from an Interface Builder 3 plugin. This gives you the ability to do this:

[NSImage imageNamed:@"IAmAnAcornFile"];

You should be able to use Acorn files anywhere an NSImage is used. Just embed your Acorn files in your XCode project resources and refer to them by name in your NIBs or in code.

I’ve put the code on my public googlecode.com subversion repository.

I’m currently on the fence about whether it is a good idea or not to ship your application with Acorn images. It certainly makes sense to me to use them during the interface design stage of application development. Once the user interface churn settles down I should be able to finalize the images and convert them to pngs or whatever (keeping the originals of course).

A best of both worlds solution might be to make a little command line tool that can convert Acorn files:

#!/usr/bin/python
from AcornImage import *
# Everything else is an exercise for the reader.

And then automatically convert from Acorn to whatever during the Xcode build process. I might investigate this technique at a later date. But for now – have at it.

Toxic Progress Indicator should still be used on apps that need to run on 10.4, but I wont be supporting the class any more (not that it is really needed any support…)

Although the SpaceNavigator support six degrees of freedom, I’m only using two (Y axis for forwards/reverse and RZ for turning), that leaves plenty of room for expansion (perhaps hooking up a third motor to another controller axis).

Although the video doesn’t show it too well, the SpaceNavigator does allow for very fine grained control over the robot (as long as the robot has fresh batteries!). The controller is extremely sensitive and with practice the robot can be controlled quite delicately.

Currently only one axis is dominant at a time (that’s actually a preference in the SpaceController System Preferences screen) but it is be possible to control robot steering and speed/direction at the same time. I’ll be trying that out soon.

There doesn’t seem to be much in the way of Mac OS X APIs for controlling NXT via Bluetooth, so I’m putting my code onto my public subversion server and releasing it (like everything else in my public repository) under the BSD License. The code is Leopard only (although all I’m using are some Objective-C 2.0 features, such as properties and the new for loop). The code uses Cocoa bindings/KVC and has a rather simple interface:

robot = [[[CNXTRobot alloc] init] autorelease];
((CNXTMotor *)[robot.ports objectForKey:@"B"]).power = (int)(theMotor1 * 100.0);
((CNXTMotor *)[robot.ports objectForKey:@"C"]).power = (int)(theMotor2 * 100.0);

The sample NXT project relies on my ToxicWarped framework. ToxicWarped was originally created for my Geode project and is designed to help write simple but flexible Object Oriented protocol stacks.

The NXT code is barely a day old, so it is very rough and ready but I’ll be tinkering with the NXT and SpaceNavigator code over the next few weeks (in my spare time) but if anyone has a use for the code and would like to contribute back that would be fantastic.

Update: Couldn’t stand awful Youtube image quality any longer. Videos are now on amazon s3.

The software that comes with the SpaceNavigator is functional, but like a lot of hardware related software is rough around the edges. You can provide customised settings for specific applications or use global settings. You can set up macros to fire when either of the SpaceNavigator’s two buttons are pressed. Understandibly the SpaceNavigator will not appear to applications as a standard input device, so 3Dconnexion provide an API to allow 3rd party developers to use the device. This opens up a host of opportunities for 3rd party developers. The Space Navigator could be used in third-party applications as a jog wheel, kind of like the Griffin Powermate and also as a 2D scroll wheel at the same time.

This leads me onto Acorn, Acorn is Gus Mueller’s newest application. It is an awesome 2D image editor, with a healthy list of features. I consider it to be a “Photoshop for the rest of us”, and has quickly become my image editor of choice. Like Gus’ VoodooPad, Acorn also supports a plug-in architecture. This allow developers to extend the applications in ways Gus wouldn’t have dreamt of (although considering Gus wrote FlyGesture I’m sure he has some pretty funky dreams). I’ve created a plug-in for Acorn that uses the SpaceNavigator API to zoom and scroll around the image you’re editing. Rotating the SpaceNavigator causes the image to rotate (using the CoreImage affine transformation filter). This just touches the surface of the cool things you can do with the SpaceNavigator and an application that supports plug-ins.

Now for the money shots, two movies of the plug-in in action:

Source code for the plug-in is on my Google public repository link, I’ve also written a Cocoa wrapper for the 3Dconnextion API (required by the Acorn plug-in): link. My Cocoa wrapper provides a much simpler interface to the device, and also provides more functionality (such as emulating a scroll wheel). I’ll be working on the wrapper more in the future.

All this code is a work in progress and you will probably need to massage the Xcode project to get it to compile. You’ll also need the 3Dconnexion API (and of course a SpaceController).

And hey look – I’m blogging again!

Update: I got daringfireballed, so I’ve moved the movies onto youtube – quality sucks, but now the server seems responsive again. Links to source code fixed.

Update: Movies now on Amazon S3. Youtube quality sucks so much. (videos still on Youtube here and here).

Unfortunately adding the cell caused drawing of the table’s window to slow to crawl. The spinning beachball of death would often appear when I was merely resizing the window. After some quick experimented I narrowed it down to something within the ‘Discrete’ variant of the NSLevelIndicatorCell, the other variants had no such performance problems.

It didn’t take an expert in Shark to realise what was going on:

It looked like NSLevelIndicatorCell was perform an expensive gaussian blur per cell, possibly even for each discrete block within each cell. For a single NSLevelIndicatorCell that shouldn’t be a real problem, but for a whole table column full of them it could create major performance problems.

Some quick google searches showed that people had complained about poor NSLevelIndicatorCell performance before but failed to find a solution.

Switching to another variant of NSLevelIndicatorCell wasn’t an option, the ‘Discrete’ variant was just too sexy. So the obvious solution was to create a subclass of NSLevelIndicatorCell that posed as the real thing, but cached the drawing code of its parent class into NSImages. So I present to the the world the imaginatively titled CCachingLevelIndicatorCell.

CCachingLevelIndicatorCell is designed to pose as NSLevelIndicatorCell but shouldn’t require any other configuration. The class will only cache images for the ‘Discrete’ variant and will use a dictionary of NSImage objects to cache the drawing (one image per discrete value the cell can display). If any other attribute of the cell is changed the class will discard the cache and attempt to recache the drawing at the next opportunity.

Just so you can compare the differences in speed I’ve created two stand-alone test applications so you can compare the speed without CCachingLevelIndicatorCell and with it posing as NSLevelIndicatorCell. The binaries are checked into my public subversion.

Radar bug: rdar://problem/4601201

NSInvocation objects are Cocoa’s equivalent of “functors” and are extremely handy. But unfortunately creating them is often a pain. For example, take the following code showing how to create a simple NSInvocation:

The code to create the same NSInvocation using my CInvocationGrabber class looks like this:

Obviously the primary benefit is that there is a lot less code. A secondary benefit is that you don’t have to store your parameters on the heap and can just pass them into the ‘grabbed’ method.

Now that I’ve been using CInvocationGrabber for a few months I find I am using NSInvocations more and more. I’m using them in places where I would normally have written a little delegate method. For example just today I needed to write code that called a method after a time delay. Normally I would have wrapped it up in a NSTimer delegate method, but with CInvocationHelper I just used the invocation variant of NSTimer. Although I wasn’t saving many lines of code in this example, I was reducing the clutter in the class.

Cocoa developers with a keen eye might spot the similarity between CInvocationGrabber and Cocoa’s NSUndoManager APIs. This code is directly inspired by NSUndoManager’s prepareWithInvocation method.