As many of you probably know, almost a year ago now I decided to take the plunge and move my primary development activities to the Mac. I taught myself Objective-C, got properly to grips with Cocoa at last, and started a new Mac OS X-specific project which would eventually become SourceTree, learning a ton along the way (a process which is by no means complete!). Happily, things have turned out very well - SourceTree continues to sell, reassuring me that there’s enough interest out there for me to keep expanding and improving it (I’m looking forward to getting the next major release in people’s hands soon), and I’ve also been getting some Mac/Ogre-based contract work which I’ve enjoyed a great deal.
Cocoa is already quite good at handling localisation - you have a folder per language where all your resources are loaded from, and you get tools for exporting your strings from your code (genstrings which exports NSLocalizedString macros) and from your user interface components (ibtool which can process nib files to export & import strings). What isn’t covered very well in the docs though is how you might automate all this so that it’s efficient, incremental, and idiot-proof.
I was thinking the other day about how many version control systems I’ve made my way through over the years of being a professional developer, and I figured it would be fun to put it in graph form. Of course, this is entirely from memory and gives the illusion of being more empirical than it actually is, but hey, everyone loves graphs, right? Yes, I really didn’t use any source control back in 1994, barring backing up to 3.
We hear a lot about globalisation these days; how money, people and business move freely around the world (although that has had a few teeny problems of late) and how countries must therefore compete in that market for investment, and ultimately jobs and economic success in general. Much of this is true and common sense, however, I do object to the tone and emphasis that is used whenever this argument is made.
I don’t blog as much as I used to, for reasons which are somewhat relevant to this post - rather you can usually find fragments of my consciousness floating around the Twittersphere instead, since its enforced brevity requires considerably less of my time to populate. Maybe I’m old fashioned, but I believe that if you’re going to write a blog post about something, you should probably make sure it’s written in a half-decent way, and that’s fairly time consuming, particularly when you’re ever so slightly anal about language as I am.
I’m still getting the odd comment on my post in April about my back & why I was retiring from Ogre - thanks again to everyone for the best wishes. I haven’t posted any updates since then, both because I don’t want to ‘count my chickens’ too early, because I’ve been busy, and because I don’t want to be too self-indulgent; but it’s been 6 months now, and I figure some people might like to know my status, because it really has changed a lot.
Wow, talk about a ‘bolt from the blue’ here: I woke up this morning to find that I’d been included on the ‘Game Developer 50’ in the November 2010 issue of the long established Game Developer Magazine. It’s entirely, completely bonkers to see my name included in the same list as the likes of Sid Meier and Gabe Newell. Just, wow. 😮 Obviously my inclusion was based on my 10 years working on Ogre - it’s somewhat ironic that I was a GDMag subscriber when I started Ogre originally, and did so with the intention of creating my own games with it, inspired by what I read in those pages.
I’m pleased to announce that I’m finally ready to make my first fully-fledged commercial Mac OS X application available to the world! SourceTree is a user-friendly Mac OS X front-end for Mercurial and Git, the two most popular distributed version control systems used today. The goal was to create a single tool which could deal with both systems efficiently, and to give a developer quick and intuitive access to the things (s)he needs to just get on with building software.
I’m 37, and I’ve been a (professional) developer for 16 years. You would have thought that in that time, I’d have figured out an effective work style which delivered the desired outcomes (code cut, products shipped etc) without causing detrimental knock-on effects - but, sadly, you’d be wrong. I think the style in which I practiced my craft for the first 15 years of my career was much the same as every other enthusiastic developer: you put a ton of hours in.
I only started learning Objective-C and Cocoa in mid-May, and for the first time I think I actually have a tip to contribute to the wider community. It’s about using custom cells in NSOutlineView, but those which you want to design inside Interface Builder rather than drawing manually.
If you’re an iOS developer, you’ll be wondering why this deserves a blog post - it’s easy to do in Cocoa Touch! Well, yes it is easy on iOS, because Apple have specifically allowed you to design table view cells in Interface Builder. When targetting Mac OS X though, it’s actually pretty awkward, and here’s why: in Cocoa Touch, the class which draws the cells in a table is UITableViewCell, which is a subclass of UIView - meaning you can drag one onto the canvas in Interface Builder and lay stuff out right there. In Cocoa, in contrast, the cell is simply represented by NSCell, which is not an NSView subclass. This means Interface Builder will not let you play with them, you draw them by implementing drawWithFrame:inView: instead. I think Apple realised the problem with this design in time for Cocoa Touch but obviously felt they couldn’t break the existing Cocoa interfaces. There are also many differences between the instantiation of NSCell versus UITableViewCell - there’s only one NSCell for all rows in a table / outline view, compared to a type-indexed pool in Cocoa Touch.
The problem boiled down to this: if the contents of your table / outline cell is non-trivial, or if you just don’t want to write a bunch of layout code, it’s a PITA to implement a custom look in NSOutlineView, such as the one in the picture, especially if you want custom controls embedded in it. For my current Cocoa app, I really wanted to design my cells (and I have 2 different styles for group levels and detail levels) in Interface Builder to save me hassle, including using Cocoa Bindings to hook up some dynamic fields within. Many internet searches later, and mostly the answer I found was that it couldn’t be done. Luckily, I’m too stubborn to take no for an answer, and eventually I figured out a way to do it. Details are after the jump, with an example project to show it in action.