Rubyfocus beta


Rubyfocus is a pure ruby bridge to OmniFocus. It’s something I’ve been working on for a while, and I’m finally able to release a version that, at the very least, functions without crashing (as far as I can tell) anywhere along the way.

Rubyfocus started as a natural offshoot of a previous project, JROFBridge. JROFBridge is an objective-C/Cocoa library that accesses OmniFocus through ScriptingBridge, collects data on projects, tasks and folders, and outputs it to an SQLite database. It’s a handy way of collecting everything you need to know about an OmniFocus document, working through OmniFocus itself. I used it for a web-based Kanban frontend to OmniFocus, which let me view all my projects (and my current workload) at a glance.

In the last six months or so I’ve been moving away from OmniFocus for a lot of my task-management - not out of choice, unfortunately, but out of necessity. Even before then, Apple’s release of the Swift programming language meant that JROFBridge was slowly becoming obsolete. At some point in the future I’d like to sit down and really learn Swift - but for a lexicographer juggling numerous side-projects, the idea of getting stuck into an entirely new programming language is somewhat daunting. Both these factors meant that I really didn’t have the motivation to upgrade or improve JROFBridge.

Rubyfocus originally started when I realised you could access all of OmniFocus’ document data through their OmniSyncServer web-based sync service. In fact, once I started poking around at the internals of OmniFocus, all that data is stored in handy XML format on your computer. Sure, it’s not the most easy-to-read format: in order to make syncing work across multiple devices, OmniGroup stores OmniFocus’ data as one “base” XML file, followed by a series of patches, and assumes that the program will be able to apply said patches to come up with the final document. But reading it is possible.

Rubyfocus does just that: it reads the local files, uses them to construct a “final” image of the OmniFocus document (including every task, project and context), and then provides it as a series of ruby objects. This has a number of advantages over the old ScriptingBridge method:

  • The majority of my coding is in ruby, and using Rubyfocus means I don’t have to rely on an external program to get my data for me. Also, it’s nicer to have direct access to all my projects and tasks in-program, rather than relying on an SQLite database.
  • Programs are no longer limited to running when OmniFocus is open. The data is accessible at any time.
  • It should (hopefully!) be relatively easy to get RubyFocus to talk to the OmniSyncServer. Which means that you could run scripts on computers that don’t even have OmniFocus installed.

These are all great reasons why Rubyfocus is going to be the future of my OmniFocus hacking. In the near future, I hope to update my locally-hosted kanban site to use Rubyfocus, and then maybe it’s time to play around.