JRuby GUI MVC Framework Monkeybars Goes 1.0
There are many JRuby libraries that try to make GUI development with Java toolkits easier.
We talked to James Britt of the Monkeybars project. James' elevator pitch/elevator explanation of Monkeybars is:
Monkeybars is a JRuby MVC framework that sits on top of Swing. It doesn't wrap Swing per se, but instead presents view logic (encapsulated in Swing classes) separate from controller and model logic (in Ruby). In that sense it exploits the freely available, high-quality WYSIWYG Swing UI design tools while freeing you to develop in Ruby. Initially extracted from real-world applications, Monkeybars was designed with testing and maintaining large applications in mind.
James explains how Monkeybars handles interaction:
One goal of Monkeybars is to decouple the view and the controller; a controller should never need a direct reference to a view. Instead, it uses signals to indirectly inform the view that something should be done. This makes it much easier to test the controller, since you do not have to worry about the UI.
Monkeybars doesn't come with a way to build the actual GUI components, instead it allows to choose the GUI building method.
Monkeybars expects to have classes that represent a Swing UI. At Happy Camper we almost always use the Netbeans UI editor to draw and compile down the UI objects, then reference them via Ruby code in the application. In principle you could also use Profligacy, Cherry, or even SwiXML + Builder, though I've not seen code that does that. (Also, see my comment later on about planned additions to Monkeybars and making it easier to write in-line Swing code.)
James explains how developers are using Monkeybars:
Most users of Monkeybars are using it in greenfield JRuby applications, but we know of at least one person who has dropped it into an existing Java application. Monkeybars is available as both a gem and as a jar. (And as source code, of course.)
We asked whether it'd be possible to use Monkeybars for GUI scripts inside an existing application:
[..] In a Java app you can load and execute Ruby code, which could use Monkeybars, or in a Ruby app (assuming it is run under JRuby) call Monkeybars when you wanted invoke a GUI.
However, your question got me thinking about tossing up a desktop GUI with code that normally didn't offer one. For example, while developing a Web app, it might be nice if errors were rendered in a nice GUI rather than in the browser or the terminal. Turns out it's really easy to hook Monkeybars into a Ramaze app so that you can render a Swing form when you want one. Turning this into a nice multi-windowed GUI console app, with hooks for viewing source code and docs, would be an interesting project.
Rawr is a tool that's useful when developing Monkeybars applications. James explains rawr:
Rawr is another project that evolved out of real-world needs. It bundles up your Monkeybars app into an executable jar by providing some useful Rake tasks. You can also make a Windows .exe file, or a Mac .app. (We're working on adding a Linux packager.) This includes icons, media/content jars, and even compiling your JRuby into classes to help speed up load times. This is how we package up releases of JotBot, our time-tracking app which we believe is the first commercial JRuby desktop application.
We asked about Monkeybar's future, post 1.0:
The core is pretty solid now, and hasn't had any significant changes in almost a year. We have a few large production apps that would be painful to refactor if we made big sweeping changes right now, so we're probably just going to build off of this foundation instead of changing it.
However, with this stability, there are some "nice to have" features we're considering. For example, we're looking at making it easier to create the Swing UI classes using a custom DSL or builder syntax. Swing is huge, so we won't pretend to try to wrap all of it, but many basic UI forms and components should be more easily available in conventional Ruby syntax.
Given that, we can look at application generators. Many apps have a set of common forms and behavior: splash screen, system tray icon, help and "about" forms, and so on. It should be easy for someone to get a minimally functioning desktop app running in a few command line calls or Rake tasks. The app can then be fleshed out, with additional UI components built using either inline code or compiled Java classes.
Logan has been working on view bindings, which is an easier way to do mapping with your model and view, and making the data seem as if it's always in sync.
Another project comprises some helpers for common things that we think Swing should be able to do, but currently doesn't, or doesn't do easily. For example, being able to disable specific items in a combo box, or context menus for text fields. Yet another endeavor is getting Cucumber + RSpec to play nice with Monkeybars; there are some tricky bits down that path.
Finally James provided a list of resources and places to follow Monkeybars development, or ask questions to the Monkeybars core team (currently James, Logan Barnett, David Koontz):
There's monkeybars.org of course; we're in the process of updating docs and screencasts for the 1.0 release.
We're on IRC at #monkeybars on Freenode, and there's a Monkeybars Google group, too:
Logan Barnett blogs about Monkeybars as well:
There's the video of David Koontz at RubyConf 2008:
Martin Slader covered Monkeybars at Ruby Manor: http://rubymanor.org/videos/gui_manor_born/
People can try out a commercial Monkeybars app for themselves by downloading JotBot and a requesting a free trial key:
We're also starting to move some things to Kenai so that we have a more stable home for user-supported documentation.
We'll put details about that on the Monkeybars home page as they get sorted out.
And you can follow us on twitter:
What do you use to build GUIs with JRuby?
It did never feel right for me to try textual DSLs for GUI design, since it is a visual process and works best with visual tools.
Monkeybars is a good example for a hybrid Java+Ruby design, where the combination is superior to either language alone.
How Can We Use Our Creative Power and Technological Opportunity to Address the Challenges of the 21st Century?
Gyorgyi Galik Feb 26, 2015