Mac
My primary development machine has been a series of nicely specced MacBook Pros for about 7 years. Over that time I’ve grown to love these shiny boxes of aspiration. My current machine dropped out of AppleCare in 2016 though, so it was time to start thinking about a replacement for my main work machine - as usual the previous model would be downgraded to our casual machine and would stick around for a good few years afterwards (or so I thought).
I alluded in a previous postto the fact that I’ve chosen Mac for all my development activities. I’m aware that in game development (outside iOS games), this is perhaps not the most common choice. Apropos, I saw a tweet thread last week, not gamedev related, where a heated debate broke out about what platform/editor/language ‘real’ developers use. I’ve lost track of the number of times I’ve seen threads like this, where opinionated developers try to tell others what choices they should be making.
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.
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 Twittersphereinstead, 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 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 Mercurialand 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 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.
I came across a couple of interesting issues when I came to do the first pass of writing the text for the user-visible strings I’d been setting up for a Cocoa app I’m writing (painfully slowly as I learn the nuances of the environment), and I thought I’d share them. Full details are after the jump, since I’ve embedded a large script in the post.
The basic principle for text localisation on OS X is that, like most systems, you externalise your user-visible strings in string tables and reference them by keyed aliases in code - in this case using NSLocalizedString. Apple provide a tool called ‘genstrings’ which extracts all these into a template strings file called Localizable.strings which you can then populate per language - localised files are kept in folders called en.lproj, fr.lproj etc and helpfully they’re picked up by default like this. So far, so good.
Giving up the leadership of OGREwas a sad moment for me, but in hindsight it has also been rather liberating. For 10 years I’d spent most of my energy on OGRE or on projects that were related to OGRE. There was an implicit understanding both from the community and from myself that everything I embarked on would in some way tie into OGRE - and indeed my business has always been based on a constant balancing act between how I can make a living while also promoting and advancing OGRE.
Yesterday saw a triple-whammy of sugary Apple gaming goodness: Steam for Macwas released, meaning all the games you own on Steam that are ported to the Mac can also be played there, free. Torchlightwas a day-1 release on the service, meaning Ogre (and therefore code written by me) was among the very first on the service. Portalbecame free (for Mac and PC) Wow. A great day for Mac gaming.
I can’t believe this is the first time I’ve needed this on OS X, but it came about from needing to write a document for a European customer and suddenly realising I didn’t know how to make an umlaut on my Macbook Pro’s British keyboard. On Windows I might fire up the Character Map, but I didn’t know how to do it on OS X. Here’s what I discovered: OS X friendly apps like Mail, Safari, iCal and even Firefox have a ‘Special Characters’ entry on the Edit menu which brings up an equivalent of Character Map.