2016

Not dead but feature-complete. Unless something is simply broken (perhaps because of a change in JRuby) there's little reason to add or change anything.

The best place to stay on top of this is the Github repo.

Update: October 2011

Monkeybars is still in active development. Mostly that means making sure it continues to work with each new release of JRuby. Monkeybars, for the most part, is feature-complete.

The current JRuby is 1.6.4, and work is underway to check Monkeybars (and Rawr) against this release.

This Web site also needs various updates and changes; in the meantime, apologies for the cruft until it is cleaned up.

Please note, too, that this is the current Web site. The pages on Rubyforge.org are vestigial junk that needs to disappear.

About


Thanks for checking out Monkeybars. This is a library that enables you to make use of Swing from JRuby. Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. In fact, with most editors you’ll never even have to look at the Java.

Philosophy


Origins


Monkeybars was created from a pretty specific need. A few years ago, my former company, Happy Camper Studios, was working on a large Swing application and we wanted to be able to easily write all the logic in Ruby via JRuby. Our initial attempts laid the groundwork for what was to become Monkeybars. Because of our needs, Monkeybars has an emphasis on using normal Swing development tools (we were using Netbeans 6) and especially the ability to sit down with a client and use a visual designer to create the Swing layouts. To this end, Monkeybars is designed to reach in and integrate itself with a Java class without any special consideration on the Java side. This means Monkeybars should work with Java code emitted from any Swing form designer, we don’t parse the code directly so there is no issue with code formatting or code conventions used inside the class.


So, what do we mean by “easily”? Well, I’ve got a pretty low tolerance for pain in my code so ideally everything gets reduced down to a one liner. Want to set up mouse event listeners on all elements in your form?


add_listener :type => :mouse


Or how about declaring that only the components okButton and cancelButton should get mouse events?


add_listener :type => :mouse, :components => [“okButton”, “cancelButton”]


How about sending some long-running task off to its own thread without freezing the GUI until it is done?


repaint_while { # call some long running method }

Still not convinced? Go so more code samples on the examples page.

Testing

A second important consideration for us was testability. Our early attempts to create a Ruby interface to Swing left us with brittle, difficult to test code. Therefore in Monkeybars we implemented a stark separation between controller and view. All* communication between the two is accomplished via a model which is just a plain Ruby class. This keeps your controllers much more testable. The views also are typically smaller and much easier to test, only being concerned with their methods to convert data from and back into the model.

* I say all but in reality there is direct communication between the controller and the view, it’s just behind the scenes so you don’t have to think of it in terms of direct communication.