Developer diary: plans and progress reports.

By browsing this website you are agreeing to our use of cookies.

The road ahead Saturday 13th December 2008

Now that Boxer’s feature set is fairly stable, it's high time I picked up a Cocoa handbook, pulled my finger out of my ass and learned to write proper Mac applications.

I’ve developed Boxer this far in Applescript, a MacOS scripting language intended for inter-application communication. Initially this was a quick and dirty way to tell DOSBox to do what I wanted; the codebase grew shambolically from there, as Boxer matured from an ad-hoc wrapper script to a released application, and by now Boxer’s humble beginnings are a ball and chain.

Applescript was not meant for yoking to the plough of a fully-fledged app. The language itself is long-winded, fussy and brittle; more relevantly, its libraries lack support for proper interfaces or persistent application behaviour. Hence each session of Boxer has a very short lifetime, with no interface to speak of—it relies on Applescript’s built-in dialog functions—nor any facility to store application preferences beyond the configuration files for DOSBox itself.

These limitations have helped to keep the application brutally simple: but they have also obscured a lot of Boxer’s behaviour, because the application has few ways to expose features or communicate progress.

Whither is it bound then?

I have grander plans for what Boxer will become once I migrate it to a proper framework, though I'm conscious not to lose sight of what makes Boxer work well. My main concern is to provide a more elegant interface for the installation/package creation workflow, and provide more feedback about what Boxer is doing in general. A proper menu system and welcome pane for common tasks would help expose Boxer’s feature set and make interactions more fluent and obvious.

It also needs a simple preference pane for tweaking common options: Boxer’s folder locations, whether to start in fullscreen or a window, whether to lock the mouse when you click, whether to apply any graphics filters, and things of that ilk. DOSBox itself will pick up some additional hacks along the way to make it cooperate better, but those are beyond the scope of a single post.

Other DOSBox emulation settings will remain strictly auto-configured for now, as I have yet to find any configuration issue in Boxer that warranted a GUI for such settings. Such interfaces are disaster areas in every frontend I’ve used; reconfiguring a game requires so thorough a knowledge of DOSBox’s inner workings that a “user-friendly” interface for doing so inherently isn’t, and Boxer’s raison d’être is to save you from having to care what things like dynamic core emulation mean. It was bad enough in the old days.

Further along the road, I’d like to offer an elegant game browser complete with shelves à la Delicious Library. This would allow me to do a few extra tricks that aren't possible through Finder: such as dragging an image onto a package to apply it as cover artwork, and grouping games by tags and other metadata.

For now though, Finder + Spotlight does a much better job as a game browser than any frontend I've seen; the last thing I want is for some overbearing iTunes-alike interface to usurp that simple and flexible approach.

Design by 40watt.