The new version of Mac OS X, Leopard, came with a much anticipated feature - an officially supported set of Ruby bridges to Cocoa (the Mac OS X Framework) and AppleScript. Digging around I couldn’t find the pre-installed versions, but it was easy enough to gem install rb-appscript

I’ve been playing around with the very complete examples over the last couple of days and am really impressed with how easy it is to build Cocoa apps in just a few lines of Ruby code and using the new InterfaceBuilder. You get full-fledged support of all OS X’s goodness without having to worry about Objective-C.

However, I hadn’t fully considered some of the implications of this until I was stumbled across the open-source OmniFocus-UI. It is a Rails app written as an iPhone interface to the Productivity application (GTD) OmniFocus. It essentially provides a very lightweight web interface to the application by way of the AppleScript interface. rb-appscript and RubyOSA are two Ruby AppleScript bridges that make AppleScript actually really nice to work with.

The fact that it’s a Rails app is almost silly. There is no database connection to speak of. All storage and primary functionality is handled by the app itself. OmniFocus-UI could probably be rewritten as a Camping or Merb application very easily with a much smaller footprint.

The way the Rails app works is that the controllers just route commands via rb-appscript. So when you want a list of contexts (organization of todos), the Rails app just needs to do the following in Ruby:

require 'appscript'
doc = Appscript.app("OmniFocus").default_document
doc.contexts.get.length

Or to see how many Inbox items you have:

doc.inbox_tasks.count

If instead you want to use RubyOSA, it’s really just the Class name that changes (and some more underlying bits):

require 'rbosa'
doc = OSA.app("OmniFocus").default_document

What this means is, it’s very easy to build web interfaces on top of any AppleScript-able Mac application. The one difficulty, however, is configuring your Mac to make it easily externally accessible from anywhere on the Web. If you’re handy on IT, you can always setup port-forwarding on your router.

However, if you just want setup & forget, you should check out Prism (http://goprism.com) - which creates secure, private web accessible connections to your home computer.

I haven’t tried it yet, but the new Mac OS 10.4.9 update fixes a problem in Aperture:

GPS metadata is preserved when image versions are exported.

And there was much rejoicing… Yay!

This is actually a really common problem with most photo-editing programs. You’re lucky if they retain much, if any, of the EXIF metadata for an image. All that time spent putting in Copyright, Headline, Caption, Location, Subject, etc. is usually probably lost the minute you export to JPG or upload to Flickr. It’s nice to see applications, especially professional-grade ones, supporting the additional metadata.

The Update addresses another issue I ran into the other day:

Addresses an issue in which incorrect encoding could be used for the files created by the “New Text File” Automator action on Intel-based Macs.

I was trying to setup Automator actions for my Pertelian X2040 LCD in an upcoming MacTech Magazine article. Now I can add lines for upcoming iCal events, Mail messages, and perhaps even pipe these out to my NabazTag!

Leopard will officially support Ruby & Python bindings in Cocoa which is terrific news. I’m a big fan of interpreted languages when appropriate.

Of course, there are about a dozen other very cool technologies for developers in Leopard that should really make application development, faster, better, and more fun. I’ve gotten a chance to play some with Leopard previews, and the actual User-facing improvements are minimal. But what users will eventually get will be lots of better third-party applications. (via Theocacoa and Michael McCracken)

It’s great to see how much effort is going into not just creating slicker UI’s, but better supporting the people that really make or break an operating environment - developers. Microsoft has had a lot of developer support for quite awhile, and I constantly hear about various .NET meetings/presentations/technologies etc. Apple really kicked it off by releasing XCode for free (no ‘professional versions’ need apply) and then having terrific Developer Documentation and examples.

The Leopard developer page makes some odd claims:

Mac users love to exchange quick messages, have video conferences, and collaborate on each other’s desktops across the network.

um… right, ok. I just love collaborating on your desktop. Anyways, I can’t wait to dive in and start developing on Leopard.

MacTalk Magazine is a new, print & digital magazine out of Australia. If you don’t happen to be down-under, you can grab the PDF for free. (via Theocacao)

Overall it has a very nice layout, though I think there could be a little more line-spacing. The Short story sections that look like Safari windows is cute though the double-url’s is redundant.

One thing about Mac magazines, there are quite a few out there now, and to be honest, the community just isn’t that big to warrant 4 or 5 monthly magazines. Especially when there are so many blogs. Really, you end up getting multiple reviews on the same new products, like an external hard drive. And which magazine is going to give a bad review of a new piece of Apple hardware.

Mac Talk also has non-mac specific articles, like Depth of Field for photography, and better movie recording techniques. There is even a Programming section, which is very welcome, but perhaps a little bit out of the mainstream.

Personally, I like the idea of various levels of Mac Magazines. You have your general audience magazine, like MacAddict or MacWorld. There is the sole surviving technical magazine, MacTech, and various photography and media Mac magazines.

I’m curious as to the readership trends of print magazines to online resources, and how magazines can better blend the two. Wired, for example, published their print magazine (of which I am a subscriber) with all of their articles, and excellent layout. However, they also push their articles out online, staged, after the print magazine. Sometimes the online article comes out before I’ve gotten a chance to read the print version. This is a case of the magazine still providing the easy to use, and pretty print magazine, but gaining a wider readership and use to the community by also publishing online.

Personally, I get a large amount of traffic through my articles that have been published online through Linux Journal, whereas I don’t know the amount of MacTech-inspired readers I get.

I hope more (all) magazines follow the trend of publishing their articles online.

RubyCocoa is a bridge between the Mac OS X Cocoa Framework API that makes it callable from Ruby code. You can create applications, objects, call Mac OS X Services. You can even call Applescript:

require 'osx/cocoa'
include OSX
def speak (str)
  str.gsub! (/"/, '\"')
  src = %(say "#{str}")
  NSAppleScript.alloc.initWithSource(src).executeAndReturnError(nil)
end
speak "Hello World!"
speak "Kon nich Wah. Ogan key desu ka?"

Ben Bleything submitted a talk to RubyConf, titled “Harmonize: Exploiting RubyCocoa and Sync Services for Fun and Profit” where he discusses making a wrapper around the SyncAPI in Ruby. (blog post introducing Harmonize)

RubyCocoa looks like it may have stagnated a little as the last release was November 2005, but perhaps with such a renewed interest in Ruby, and Mac OS X gaining popularity, perhaps new life with be breathed into it. Projects such as SyncBridge and Harmonize also obviously help.

Update: Check out the very good examples and information at RubyCocoa.com, including how to use your Apple Remote from RubyCocoa .