Three approaches to JRuby GUI APIs

Swing was added to the JRE with version 1.2 in 1998, after it's predecessor AWT turned out to be insufficient for nontrivial applications. One of Swing's problems (next to the performance and Look and Feel issues) іs the amount of code necessary to build even small applications. This has lead to a host of XML based GUI definition languages to be created.

The availability of JRuby now started another wave of libraries trying to make developing Swing apps less tedious by using (J)Ruby's language features. Blocks are used to prevent Listener boilerplate and the Builder concept is used for creating complex, nested GUIs in Ruby code.

The latest API is Profligacy by Zed Shaw. It's focus is on making event handling easier, avoiding all the boilerplate necessary for AWT/Swing Listeners. The creation and set up of components, on the other hand, is quite similar to the way plain JRuby code would look, eg. creating new Swing widgets with new. A sample of Profligacy code:

@ui = Swing::Build.new JFrame, :texts, :label do |c,i| 
  c.texts = [JTextField.new(10), JTextField.new(10)] 
  c.texts.each_with_index {|t,n| 
    t.action_command = "text#{n}" 
  }
  c.label = JLabel.new "Something will show up here." 
  i.texts = {:action => method(:text_action) } 
end
@ui.layout = FlowLayout.new 
@ui.build("Two Text Fields Demo").default_close_operation = JFrame::EXIT_ON_CLOSE

def text_action(type, event) 
 puts "EVENT: #{type} #{event.action_command}" 
end

See the link for more sample code.

Cheri::Swing by Bill Dortch is part of the Cheri project, which is a framework for creating builder applications. Builders allow to create hierarchical structures with very little Ruby code.

menu_bar { 
    menu('File') {  
      mnemonic :VK_F
      menu_item('Exit') { 
        mnemonic :VK_X
        on_click { @frame.dispose }
   }
 }
}

This shows how Ruby's method_missing and Blocks are used to allow for some very compact code creating a component tree consisting of a menu_bar holding a menu with one menu_item. The method calls all take Blocks (the code in braces) which are executed. A combination of metaprogramming and method_missing is used to determine whether to create a new object or execute a method such as mnemonic on a just created object. As  can be seen with the on_click call, Cheri::Swing also allows easy event handling. The on_click takes a block which will be executed when this MenuItem is clicked, hiding all the tedious setup of Listeners or Actions.

The experimental Swiby by Jean Lazarou clones JavaFXScript (previously known as F3)  as a JRuby DSL. While it also uses the Builder concept to create the GUIs, it also takes the bind operator from JavaFX Script. This allows to define expressions which are evaluated whenever one of the variables it references is reassigned. This takes care of event handling in a compact way. A sample:

require 'swiby'

class HelloWorldModel
 attr_accessor :saying
end
model = HelloWorldModel.new 
model.saying = "Hello World"

Frame {
 title "Hello World F3"
 width 200
 content {
  Label {
   text bind(model,:saying)
  }
 }
visible true
}

Which one of these APIs will become relevant in any way remains to be seen. Swing XML GUI definition libraries are a dime a dozen, with no end of newly created ones in sight. The difference to them is that the JRuby libraries are generally quite small, in the case of Profligacy currently 200 lines of code, with no 3rd party dependencies. This makes them easy to understand and maintain. And since they all allow to write GUI definitions in Ruby, they are also much easier to extend. If some feature or combination of components is not supported, it's possible to fall back to just handling Swing objects instead of having to lobby the library maintainer to add a feature.

Which approach to writing Ruby GUI code do you prefer?