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.
In a complete and total surprise, my cousin presented to me yesterday the result of a grand conspiracy in the Ogre community to commemorate my time as project lead - a specially designed, unique Ogre statuette! Thumbnails below, click for more detail… I literally had no idea this was going on, or that my cousin had been asked to make the delivery that day (I thought we were just meeting for a social).
It was my birthday this week, and from my wife I received Arkham Horror, a co-operative board game based on the classic role-playing game Call of Cthulhu - which in itself draws much of its content and vibe from the writings of H.P. Lovecraft. Set in 1920’s New England, in contrast to traditional western ‘horror stories’ (vampires, werewolves etc - all a bit pedestrian), Lovecraft’s world is filled with bizarre creatures and unknowable ‘Ancient Ones’ - slumbering horrors in the outer dimensions who threaten to wake and destroy the world, and the ‘Investigators’ the players control - which include doctors, archaeologists, flappers and gangsters - are trying to avert this outcome.
After hearing on Twitter how an acquaintance’s new hosting provider went ‘mammaries skyward’ this week, much to their understandable annoyance, it occurred to me that I have some recommendations I can make on this subject. While I don’t host that many sites, I’ve been doing it for long enough and had experience of both personal and medium-traffic sites that I’ve experienced the highs and lows quite a few times already.
I’ve never really liked Facebook, as regular readers of the blog will be all too aware of, but I’ve been a user of it in the last couple of years, mostly at the cajoling of friends. During this same period of time I also started using Twitter, a service which I was also skeptical about initially. Previously, I’d always relied on my blog, forums and official sites to do my interacting, and I wasn’t sure I needed anything else.
Apple’s new flagship product, the iPad, was only just released in countries outside the USA last Friday, and I was fortunate to get my hands on one on launch day. Like many Apple products, this one has divided people, with a lot of people decrying it as a device looking for a purpose, a device that falls between two stools (not as portable as a phone, not as functional as a laptop), a device that is stifled within Apple’s walled garden.
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.