Google SoC Series: Rubyland: Extending Desktop Applications with Ruby

Posted by Werner Schuster on May 31, 2007

Sections

Development

Topics

Scripting ,

Ruby ,

Rich Client / Desktop

Tags

Automation ,

Mylyn ,

Google Summer of Code

Desktop automation is a topic that seems to change and adapt. The Mac has had AppleScript for many years, and recently added Automator so users could define actions that are performed at certain events to automate boring, repetitive tasks. Windows users might use the Windows Scripting Host, Unix/Linux users might hook up to DBus to listen to system events.

Rubyland, a Google SoC project by Scott Ostler, aims to create a way to make this usable across platforms, with the scripting logic written in Ruby. He'll basically create a system to hook up handler scripts with event sources. An event source can be the file system ("A file in directory /foo was changed") or a mail program ("3 new mails"). Scott gives some other examples:

Although my focus this summer will be on the plumbing of Rubyland, there are a few initial event sources I plan to write, for the sake of demoing Rubyland, and also to have some fun. The first will be to tap into Growl notifications, as there are tons of applications out there that support Growl, and are just begging to be hooked into Rubyland. Another will detect when the contents of a folder changes, so that Rubyland scripts can act when a file or directory is modified. There are other ideas I'm playing around with, but aside from those two, we'll see how it goes.

Growl is a notification system for Mac OS X.

The details of Rubyland are based on standard Ruby libraries, as Scott explains:

Right now, the plan is to implement the core of Rubyland on top of EventMachine, with event sources communicating via either dRB or something very similar. Much of this came together in the last few weeks, and I bet the next few weeks will hold yet more surprises.

dRB, shipped with every Ruby installation, is "Distributed Ruby", a library that makes it easy for code across several Ruby runtimes to communicate. EventMachine is a library for writing network clients and servers and facilitates event processing.

Rubyland is, of course, only as good as it's event sources and scripts. Scott hopes that many will find it easy to write these components and contribute to Rubyland:

The fantastic user ecosystem that's arisen around TextMate has really amazed me. When someone puts in the extra effort to package their work for others, then there is a fantastic network effect that lifts the entire community. My goal with Rubyland is that simple desktop tasks should be easy; and if someone finds a task to be hard, then it'll be easier for the next person.

One idea that comes to mind is to integrate these event sources with tools that monitor what is going on and try to guess what the user is doing. This can be useful to associate the user's actions with OS resources that are touched. Eclipse's Mylar is a fantastic example of this. It basically allows the user to define a task, and then remembers which resources (files, source code elements, etc.) are touched in the process. If the user decides to work on another task, this information is then saved. The next time the user continues this task, the necessary files can already be opened by Mylar and the UI focussed on these resources. In a way, this is similar as to how an OS handles context switches. Tasktop Technologies now tries to bring this functionality to the desktop. This is where Rubyland's event sources come in handy - the more events can be collected, the more information is available for activity analysis.
As Rubyland is intended to work the same across platforms, this is a possible use for this, and also allows 3rd parties to write their own analysis software. Scott on this topic:

Two years ago I worked for a graduate student who was trying to study this. The problem he found was that even though many Mac applications had extensive Applescript libraries that could be used to monitor the application's state, an enormous amount of work was needed to model the workflow and resources of any given application, with even more needed to integrate two models together. Rubyland would certainly have something to offer, by providing the underlying plumbing and a number of sources out of the box. It's a tough problem, and it would be wonderful if I helped the people trying to tackle it.

Asked for how he'll handle the project and how to watch his progress, Scott says:

I want to get out an early version of Rubyland by mid-summer, and by then, to have a mailing list running, and possibly forums. So be on the lookout for that; it'll be announced on the Rubytalk mailing list, along with the O'Reilly blog. In the meantime, anyone who's interested can feel free to email me, either with what they'd like to see Rubyland do, or what they'd like to make Rubyland do themselves. No promises, but I'm always happy to hear suggestions :)

For more information see Scott's first entry on the O'Reilly blog, where he also gives some Rubyland code samples.

• Older >