Grand Central Dispatch – The Sleeping Barber Problem

I’ve written a new post on the Sofa blog about solving the ‘sleeping barber problem’ using Grand Central Dispatch and block on Snow Leopard. Check it out here: http://www.madebysofa.com/#blog/the_sleeping_barber

Forget the Code

Along with the rest of the world, I’ve been coding on Snow Leopard recently. Blocks are a great addition to the C language, irrespective of their use in Apple’s Grand Central Dispatch APIs. I’ve found one usage-pattern where they save me time (I have little to spare), reduce the amount of mundane monkey-work I have to do , and make my code more reliable. In many places blocks can save me writing a whole line of code.

Transaction-based APIs

Cocoa is full of APIs that cause the developer to start a transaction, do some work and then end the transaction. Take for example drawing something with a shadow in an NSView:

- (void)drawRect:(NSRect)rect;
{
    [[NSColor whiteColor] setFill];
    NSRectFill([self bounds]);
    [NSGraphicsContext saveGraphicsState];
    [[self shadow] set];
    [[NSColor redColor] setFill];
    [[NSBezierPath bezierPathWithRect:NSInsetRect([self bounds], 10, 10)] fill];
    [NSGraphicsContext restoreGraphicsState];
    // do some more drawing
}

The important part of the above code is between the calls to save and restore the graphics state. Quartz (the underlying drawing API) is a state-machine, so if we were to set the shadow on our existing context, all subsequent drawing would be performed with said shadow. By saving the state, we can set a shadow temporarily and the continue to draw without a shadow by restoring the graphics context to its eariler state. It doesn’t stop with shadows, though; there are a multitude of setting we can apply to our contexts.

If you forget to call +[NSGraphicsContext restoreGraphicsState] after saving a state though then that makes me a sad panda. Try flipping the context’s transformation matrix and not restoring your state. You won’t win any design awards.

We have similar issues if we are manually notifying key-value observers of changes. All calls to -[NSObject willChangeValueForKey:] must be bracketed with calls to -[NSObject didChangeValueForKey:].

It doesn’t stop there, if you’ve done any work with Core Animation, its not uncommon to want to disable the implicit animations of layers, or to make a group or animations with longer durations than default. In these cases your code is littered with:

[CATransaction begin];
[CATransaction setDisableActions:YES];
// change any number of properties on your CALayers
[CATranaction commit];
This gets old, very quickly.

Enter Blocks

Lets make our code more robust, we all like robust. Blocks are anonymous functions, we can write them in-line and the can capture variables from their enclosing scope. In real-person terms we can write methods like this:

@implementation NSGraphicsContext (ESAdditions)
+ (NSGraphicsContext *)transactionUsingBlock:(void (^)(NSGraphicsContext * /* currentContext */))block;
{
    [self saveGraphicsState];
    block([self currentContext]);
    [self restoreGraphicsState];
}
@end

In our app we can then do things like this:

- (void)drawRect:(NSRect)rect;
{
    [[NSColor whiteColor] setFill];
    NSRectFill([self bounds]);
    [NSGraphicsContext transactionUsingBlock:^(NSGraphicsContext *currentContext){
        [[self shadow] set];
        [[NSColor redColor] setFill];
        [[NSBezierPath bezierPathWithRect:NSInsetRect([self bounds], 10, 10)] fill];
    }];
    // do some more drawing
} 

We’ve now done some drawing with a shadow, and we’ve not had to write those pesky calls to +[NSGraphicsContext saveGraphicsState] and +[NSGraphicsContext restoreGraphicsState].

Readability++

The wonderful side-effect of this is that the code executed as part of the block is indented by Xcode, too. Which means we can see, at a glance, the scope to which our transaction applies. Imagine doing the same for drawing into a CGLayer, your drawing code is in the block, and it all gets rendered into the layer. Blocks help you expresses your intent. (Yes, that’s a loaded statement. Feel free to quote me on this.).

You can download my categories and functions here. With a shiny New BSD license. Enclosed I have categories on:

• NSGraphicsContext
• CGContextRef
• NSManagedObject (for writing your custom accessors)
• NSObject (for KVO)
• CATransaction
• NSAnimationContext
• NSTextStorage

Mutexes and semaphores would also be a great candidate for this. You can easily write your own equivalent of @synchronized, to work directly with pthread mutexes.

I Love Outline Views – Here’s Mine

Apps like Coda are the de-facto standard for good user-interface design nowadays. You can do a lot with the standard Cocoa controls provided by Apple, but you can’t always get exactly what you want out-of-the-box. For example, the CSS edit section of Coda has a fantastic way of dividing tasks: the animated outline view.

Rather than having a monolithic view that has all the controls grouped with dividing lines; each section, “Text”, “Colors and Background”, “Dimensions”, all exist in their own collapsible view. Clicking the separating bar animatedly expands or collapses the view.

To make one of these views isn’t quite as easy as you first think, and you can quickly go down the wrong road in the design. The super-secret trick is to *not* use Core Animation, or more precisely: ignore the lure of NSViews conformance to the NSAnimatablePropertyContainer protocol. As of Mac OS X 10.5, a few of the properties of a view or window can be animated simply be replacing calls like [view setFrame:newFrame]; with [[view animator] setFrame:newFrame];. This is fine when you have one or two views that you want to move but it’s impossible to coordinate the movements of multiple view using this API. After using Core Animation, one would expect that after a call such as [[view animator] setFrame:newFrame]; requesting the frame from the view would return newFrame. Unfortunatley it returns the original frame of the view. Only when the animation is done, do you get newFrame. Furthermore, just try setting the delegate of the CABasicAnimation object that handles the implicit animation and getting any form of useful information back. You can’t. You’re in for a world of pain if you try.

The solution: use good-ol’ NSViewAnimation. That way you can create all the dictionaries containing the animations for all the views you want to, then instantiate one NSViewAnimation object to handle the lot and set them off at the same time. Simple.

The Animating Outline View

The outline view is made up of a few classes, the TLDisclosureBar, a subclass of the highly-configurable TLGradientView; the TLCollapsibleView which has a TLDisclosureBar and any NSView you like as its subviews. A TLCollapsibleView itself can be used alone, and will animate the collapse/expansion of the NSView subview (which I term the “detail view”).

The fun part comes when TLCollapsibleViews are subviews of a TLAnimatingOutlineView. In this case, the TLAnimatingOutlineView takes over all the animations, simply asking the TLCollapsibleView that the user has selected for the NSDictionary object that describes the collapse/expansion animation. With this information, it constructs the movement animations for all the subviews below the collapsing/expanding view and handles the required change of frame size to accommodate the changing content size. It’s all quite elegant, if I do say so myself.

Not being content with example code, I’ve made sure these classes are real-world useful. This view is integral to BibTeX management in Scribbler so it needs to be good. Some of the relevant parts of the NSOutlineView API are replicated and the delegate of the TLAnimatingOutlineView gets will/did/expand/collapse notifications, along with allowing the delegate to deny/allow animations, too. Each of the TLCollapsibleViews will also ask their detail views if the collapse/expansion is allowed if the TLCollapsibleDetailView protocol is implemented. The TLAnimatingOutlineView itself works when in an NSScrollView.

The code, along with an example project, is hosted on Google Code here. It is distributed under the new BSD license.

So why is is not ESAnimatingOutlineView, why the TL namespace? Well, I’m working on something big, at the same time as writing Scribbler. Start guessing.

Update

I’ve fixed a few bugs in the code, the current version can be checked out of the repository. Fixes include: proper support for hiding subviews of the TLDisclosureBars when the outline view is resized small, a correction to the autoresizing mask of the TLAnimatingOutlineView itself, declaration of keys that the TLCollapsibleView supplies with the animation dictionaries, the delegate of the outline view and subclasses of TLGradientView are no longer unregistered for notifications that client code specifies (i.e. no longer uses [[NSNotifcationCenter defaultCenter] removeObserver:_delegate];).

Scribbler’s Image Editing Opensourced Part 1

Well since I no longer work at the NHS I’ve been working really hard on one of the great features of Scribbler, image editing. As something I wanted to put in at the very start, I was really enthusiastic to start using Apple’s Image Kit. It promised developers the chance to do very little work and still have fully-fledged image management, provided by IKImageBrowser (very good) and image editing thanks to IKImageView. Unfortunately, the latter does not live up to the hype. After battling with it for a while and trying to justify to myself that it would suffice for version 1.0 of Scribbler, it was just way too incomplete, buggy, and damn ugly to leave in. I try to work with the idea that if it bugs me, it’s not good enough.

Image Loading

Let me start with IKImageView. It loads images ok, although larger images aren’t loaded nicely: they’re drawn incrementally in a really jarring fashion, even if you pass the view a CGImageRef that’s already in memory.  That being said, it does handle quite a few different types of images, so we give it half a point.

Image Editing

The main function of such a view is not for viewing images, but for editing them within the application. Many users want to quickly change an image they’re working with and then get straight back work.  Taking our cues from iPhoto we guess that this editing will take the form of colour adjustments rotating and cropping. If we’re feeling really generous, then we can also include a straightening tool and some zooming (although the latter is relatively superfluous unless we have some sort of pixel-level editing like iPhoto’s red-eye removal or the touch-up tool).

So we’ve put IKImageView in our app, and loaded an image, we then want to change the brightness and contrast, so we double-click on the image and open up the shared instance of the IKImageEditPanel (left).

  

Compared to iPhoto’s panel (right), this is ridiculously ugly, has no icons, has an Aqua button at the bottom instead of a properly-rendered HUD button.  The biggest issue: it appears off-screen all the freaking time. Can you imagine editing a bunch of images and having to manually drag the panel to where you want it each time you open the damn thing up? No amount of setting the frame of the window or teaching it to autosave it’s position fix this, and even if we could, the first time you run the app it’s at the bottom of the screen with most of it hidden.

Lastly, you just try setting a new image in the view and getting the edit panel to do anything anymore, as far as I can tell -reloadData is a no-op, it neither reloads the data for the panel, nor makes you more attractive. The only way to fix this is to close the panel, and reopen it (and then moving it so you can see the controls).

Rotation

If we want to rotate the image we (in code) select the IKToolModeRotate mode and we get our onscreen compass:

The problem with this is two-fold: click on the image at about 3/4 the way up and the rotation compass is drawn outside the bounds of the view; secondly, the user interaction is all wrong. To rotate you click and hold ok the image and move the mouse around in a manner that’s so hard to control it’s useless. Then think about saving the image after a rotation. The view itself has no concept of a canvas, so we can’t save an angled image on a white background, and we can’t arbitrarily decide to ignore the user’s rotation setting an save an un-rotated image (rock – me – hard place). Basically the tool is broken and doesn’t provide useful functionality to users.

Cropping

Then we have IKToolModeCrop. “Fantastic!” I hear you cry. “No longer will my users have to open up another app to crop an image, and I won’t have to write that code”. You diligently select a region if the image, then call -setCurrentToolMode: and….

Nothing. Nada. Zip.

Reading through the programming guide tells us that Apple have declared the mode and not implemented it (apoordesignersayswhat). So we then have to do it, but can we get the selection rectangle? Of course we can’t! So that nice crop button we made goes to waste, unless you want to subclass, track the mouse, interrupt -drawRect:, apply the crop using core image (note to all that CICrop filter is not a magic bullet), draw a CGImage with the cropped version, then reset the image. No thanks. On it’s own that might be fine, but with all the other rubbish in this class you’re starting to flog a dead horse.

So that’s why IKImageView will *not* be making an appearance in Scribbler, and if you find it in any other apps then… well… I heard that Windows Photo Viewer Deluxe Family Millennium Media Edition is fantastic.

Scribbler

I’ve been putting off writing about Scribbler for a while because it’s really difficult to put into words properly the ideas I want to convey. I’ve become very attached to my little application since its early inception, not only because of the time I’ve spent, but also for how it has helped me find my creative side. The only reason I haven’t put screenshots up yet is because I’ve been talking with a designer about making the icons, and developing the site and brand of Espresso Served Here (need to catch myself each time I write ‘severed’). They guys I’ve got to do that part of the app, which is completely beyond me, are really talented and I’m getting very excited about having all the artwork finished. As soon as it is ready, I’ll start posting screenshots.

It was writing my MSc thesis that gave me the desire to write a new LaTeX editor. I decided that I needed an app that understands how people work with large documents. Specifically, people work on projects. Each of these projects can contain many source files: LaTeX source itself, images, BibTeX files and PDFs; and Scribbler knows how to handle them all. You organise your project in Scribbler just like you’d organise your iTunes or iPhoto library, while Scribbler takes care of files on your hard drive. You can make new LaTeX and BibTeX files within Scribbler itself, or simply drag-and-drop a file from any other program to add it to your project.

When writing, having Scribbler keep track of your project soon shows its advantages over keeping each document separate. To include an image in your LaTeX source, just drop it on the text and Scribbler will write the code for you. You no longer need to care where the image file is in the filesystem, why should you?

Another plus to this approach comes when writing labels and citations. As Scribbler looks after your project it knows all the \label{} keys you’ve written and will suggest them for you when you type \ref{} (for the LaTeX-uninitiated, that makes cross-referencing very, very easy). The same works for all your citations.

One of the things I always found myself doing when writing in LaTeX was editing my images so I decided to add some image-editing functionality for common tasks. Scribbler allows you to re-colour, crop, rotate and apply filters to your images, so you only need to open up Pixelmator or Photoshop when you really need to.

I’m really looking forward to showing off Scribbler to you all, and when you use it I’m sure you’ll agree that creating beautiful LaTeX documents can be done in a beautiful environment. After all, one of the reasons we all use LaTeX is because we care about how things look. I’m working really hard on some features that will blow you away, and I’ll keep-on making it better.

NSViewController Late Night Cocoa Episode

You may have seen the articles Cathy Shive and I wrote on her blog about NSViewController and how to get it working well in your apps. Well now you can hear us talk about it! Scotty of the Mac Developer Network kindly had us both on for an episode of Late Night Cocoa, which you can download from iTunes here. It’ll be on the MacDevNet site too.

I talked about my preferences window system, I’ll have to wait a few weeks until I can put it up here with a sample app. Work will let up in August and I’ll have time to iron out a few bugs.

Thanks again to Scotty for having me on the episode, it was awesome!

Site redesign imminent

I’m slowly getting everything ready to get espresso served here off the ground.  Part of that has been talking to a couple of graphic designers about site design and icon design.  After all, I’m a programmer and I can’t draw for the life of me.  Photoshop to me is an app that just puts loads of stuff all over my system.

Hopefully sometime in August things will start to take shape.

Creating iTunes Scrollers

Apple introduced new scrollers in iTunes 7 and then moved on to give us the HUD, which many developers want their own scrollers for too. In Leopard, many of us thought that these would come in a nice, shiny box; but as they didn’t we’re all forced to roll our own. The common method is to draw all the components in Photoshop and then make a composite image when subclassing, but now with NSGradient and some nice additions to NSBezierPath all these have become quite easy to do, even for those with little artistic ability.

New Site Address www.espresso-served-here.com

Hi all,

Just thought I’d let you know that you can now reach this website at http://www.espresso-served-here.com. I’m going to slowly be making changes to the site as I develop the brand for my software company. All previous links around the web to http://jonathandann.wordpress.com will still work though.

Jon

NSTreeController and Core Data, Sorted.

Having recently taken the plunge into Core Data I decided it was time to rip out all the model code from my current application and replace it with a Core Data version. After about a day I had my app up and running again but with one huge problem, the content of my NSOutlineView always appeared in a random order. Such is the problem with Core Data that NSManagedObjects store their to-many relationships in an NSSet, not an NSArray, which is unordered. So when your NSTreeController tries to display its data it appears in a random order.

This is not nice, imagine if the playlists in your iTunes library always changed their order? It gets even worse if your user wants to use drag and drop. In this case they decide the order, and they’d probably want it to stay that way.