Archive for the ‘Cocoa’ Category

RapidAlbum 2012

Thursday, January 5th, 2012

I thought it was probably worth a post explaining where I am with RapidAlbum.

I abandoned a complete rewrite of the plugin before Christmas, as the plugin was growing in scale and looking like becoming a bit of a monster. My goal with RapidAlbum is to make it easier to use – the rewrite looked like it’d make it a lot harder to support, which is most decidedly a non-goal. A lot of the complexity was centered around the support for image warehousing, which turns out to be quite complicated to make suitably robust.

When you talk about support load on free software, many users will kindly say “but I’ll pay for support!”. I’ve been lucky to have a lot of users who like RapidAlbum enough to offer to pay for it. That’s very kind but I actually have a day job that I enjoy – for the moment, Mac software is a hobby rather than a career. The support load that RapidAlbum presents has to be kept somewhat in check.

So what happens now? Well, my short term goal is to produce regular releases. I’m going to be tackling small problems and feature requests in RapidAlbum and fixing them for a while. I’m also going to be reworking the UI to get it closer to what I actually want.

The big goal in the near future is a change to the way templates work. I’m planning on bundling all the extra templates inside the plugin (so they’re installed automatically). I’ll also be culling out some of the older templates. One of the reasons for doing this so that I can add a better interface for template options – I’d like to be able to offer an easy way to control features in prettyPhoto, Galleria, et al without having to manually edit the template (altho’ I’ll still allow that).

I’d actually written a fair bit of this code for the rewrite I abandoned. I’ll be reworking those changes into a release in the next month or two.

A little more info

Monday, May 25th, 2009

A few folks have dropped me email to ask about what I’m planning for RapidAlbum 2.0. As I’m still working thru’ some of the basic details, I’m a bit loathe to commit to what’s actually going to be in there but it does look (at the moment) as if it’ll be a ground-up rewrite. The basic code grew a bit organically during the alpha and beta phases of the 1.0 release and I really want to rewrite a lot of the core so that it’s more flexible (and maintainable).

The good news is that I’ve started on it. A lot of the projects that I work on for myself seem to need the same things over and over again. For example, MetaSync and RapidAlbum both need fairly extensive image metadata support and, until now, they’ve gone about that in a fairly separate way (MetaSync is Applescript Studio and RapidAlbum is obviously in cocoa).

In order to reuse as much as possible, I’ve started to strip out a lot of my existing code into general cocoa frameworks so that I can leverage them in lots of different projects. I should have done this a while ago but it’s not always easy to see the wood from the trees. This is what I’m busy working on right now.

I now have a standard metadata framework that will read image metadata from iPhoto, Aperture, MediaPro, Expression Media and the Finder into a common object structure. The goal here is to allow RapidAlbum to build smart web albums (i.e. it can interrogate iPhoto for all the photos in the “Santa Cruz” album) and to allow the next version of MetaSync (which I think will be called “Metal”) to synchronize between applications.

I’m hoping that once I have the basic support for other features (I need a general Inspector framework too), actually rewriting RapidAlbum will go really quickly.

We’ll see…

Subclassing NSMutableDictionary

Wednesday, July 11th, 2007

Although I haven’t posted much, if anything, on Cocoa programming I thought I’d post a bit more over the next few months. I’ve been coding in Cocoa for quite a few years now and it is, by far, the most productive application coding environment I’ve ever worked in. Unfortunately, the scope of Cocoa is huge and, if it wasn’t for other Cocoa programmers posting hints, notes and tips, I’d still be scratching my head about topics like drag-and-drop weirdness with NSTokenField bindings (more on this in a later post).

So this is to try to repay the favor to other coders who’ve struggled with the same things I have. And where better to start than one of the uglier problems that many programmers run in to; subclassing class clusters. The Cocoa designers, in their infinite wisdom, decided to make a few of the core Cocoa classes based on a class cluster and not concrete. This makes them awkward to try to subclass as you have to work out all of the primitive methods and provide support for them in the subclass.

Most folks end up giving up in disgust and wrapping things like NSMutableDictionary. However, once in a while, you really, really, really need to subclass it. In my case, I wanted a basic class that I could use in RapidAlbum that would call a delegate when an object in the dictionary was added or changed (so that I could flag a page export). However, I really wanted a dictionary interface as I wanted to be able to leverage all the existing NSDictionary methods (like dictionaryFromDictionary:) as the whole point is to avoid writing more code.

The trick here is to catch setObject:forKey: and removeObject:forKey: and add a delegate call. Note that if you could easily register a wildcard key-value observer for a container class that tracked all key/object changes in the class, then this would be unnecessary. That’s an expletive-laden rant for another day.

There’s a few pointers out there as to how to subclass NSMutableDictionary but nothing that really covers all of it. So, without further ado, here’s the approach I took.