Ruby GUI Toolkit Talk: Notes and Audio

On March 27th I gave a talk at the St. Louis Ruby User Group about Ruby GUI Toolkits. As with my last few talks, there were no slides, but rather a handout. The original handout fit tightly on a single, two-sided printed page; I’ve expanded the materials slightly and pasted them here.

I also recorded audio of the talk with my Olympus WS-100 digital voice recorder, then used Audacity to clean it up; Audacity’s “Remove Noise” feature worked surprisingly well. The recording lasts 1 hour 23 minutes, is 49 MB in size: RubyGUIToolkitTalk.mp3

A transcript of the talk is also available.

In the audio I mention screen shots and demos; you can find those at the respective toolkits’ web sites (linked below). I also briefly discuss and demo some code from a 2005 talk about Swing.

The handout contents follow below.

Ruby GUI Toolkits

St. Louis Ruby UG – http://stlruby.org – March 27, 2007

Kyle Cordes – http://kylecordes.com – Contact me via my web site

These notes will on my web site sometime this week.

Agenda
  1. Review the myriad options

  2. Let’s see some code

Ruby is quite popular for web applications (mostly with Rails) and for utility scripting. But there is a world of GUIs beyond web applications, a world which is not going away. To build such applications in Ruby, we must choose a GUI toolkit and Ruby bindings. My criteria for a rich client application toolkit (or the resulting application) are perhaps harsh:

  • Polished, rich set of widgets (Consider the vast array of widgets available for .NET, Java Swing, Delphi, etc.)

  • Consistent, comprehensible API, with both API reference and “how-to-use-this” narrative

  • Robust, production-grade: No beta, no pre-1.0.

  • Features beyond what’s readily possible in a web application

  • Look like 2007, not 1997

  • Look and feel, if desired, like a mainstream GUI application

  • Actively developed and updated

  • Ideally cross-platform; at minimum, great results on Windows, where most of the customers are.

  • Sufficiently popular that programmers and community resources are available

In summary: it must be suitable for creating applications that people will pay for. Not merely pay for in a vacuum or an internal-project-single-bid situation, but pay for in a competitive environment where I am trying to outmatch others who are using Java Swing, Java SWT, MFC, Visual Basic, Delphi, etc.

I investigated each option enough to form an opinion of its suitability according to the criteria above. With some of them this took only a short while. Here they are, alphabetically:

Cocoa

Sadly, I don’t have a Mac. If I did (and was targeting that platform only), the Ruby-Cocoa bridge would be very appealing, as it produces applications with a completely native Mac look&feel, and appears to be a joy to program.

http://www.rubycocoa.com/

http://rubycocoa.sourceforge.net/doc/

Fox

The Fox GUI toolkit was somewhat weak when I first learned of it a few years ago, but appears to have improved considerably since then. It uses non-native widgets (which resemble “vintage”, pre-XP-Themeing Windows controls), and has a somewhat limited selection of them. http://www.fox-toolkit.org/

FXRuby, the Ruby binding, is in the “one click installer” box. The benefit of being in the box is hard to overstate.

http://www.fxruby.org/

http://fox-tool.rubyforge.org/

Gtk

Gtk, the graphic toolkit from the GIMP and Gnome problems, is a strong candidate. Gtk is stable and well documented, and thoroughly proven by the large number of polished Gtk applications for Gnome. Gtk feels most at home on Linux, but also works on MacOS and Windows. I didn’t try MacOS, but I found it works and looks good on Windows.

Glade, the Gtk GUI design tool, treats GUI layout as data rather than code. (NeXT did this in the 1980s, and MS has recently reinvented it in the form of XAML.)

To install Gtk-Ruby on Debian (from http://ruby-gnome2.sourceforge.jp/hiki.cgi?Install+Guide+for+Windows):

sudo apt-get install ruby-gnome2

Then to try it out:

ruby -r gtk2 -e ‘Gtk.init ; Gtk::Window.new.show ; Gtk.main’

Unfortunately the simple invocations above didn’t work for me; but with a bit more work the samples run well.

JRuby + Swing, JRuby + SWT

Java Swing or Eclipse’s SWT can be used with JRuby. I didn’t investigate these much (aside from running the samples), because JRuby was not yet “ready for prime time” yet, as of around the end of 2006. It looks like there has been a lot of progress since then, so if you are reading this in mid-2007 or later, give it a close look.

require ‘java’

JFrame = javax.swing.JFrame

frame = JFrame.new(“Hello Swing”)

frame.getContentPane.add javax.swing.JLabel.new(“Hello World”)

frame.setDefaultCloseOperation JFrame::EXIT_ON_CLOSE

frame.pack

frame.visible = true

Local Web Application

Ship a “local” web application: install Rails + Mongrel + etc., and launch a web browser pointed at http://localhost:port. AJAX or Flash can be used to build a richer GUI than you can get with plain HTML. Aside from the local install process (which is not difficult), the tools are mature and powerful, and programmers are abundant. Because of these advantages, and because of the various problems with the GUI toolkits, I would consider this strongly if I needed to build a local Ruby GUI app today.

.NET

There is a Ruby-.NET bridge which can use WinForms (in .NET 1.x), but it hasn’t been updated since 2004.:

http://www.saltypickle.com/rubydotnet

There is at least one Ruby compiler in development which targets .NET (analogous to JRuby). When that is ready, it will be possible to use WinForms and WPF (the new “Vista” era .NET GUI toolkit).

http://www.plas.fit.qut.edu.au/Ruby.NET/

OpenGL / SDL

There are Ruby bindings for OpenGL and SDL; I didn’t investigate these because they are most suited for producing graphical / game software rather than application GUIs. However, as application GUIs become richer, I expect the two categories to merge to some extent, so don’t rule out this approach completely.

http://ruby-opengl.rubyforge.org/

Qt

Qt is mature, stable, and of high quality. It is used for many commercial applications on Windows and Linux. The documentation is extensive and GUI layout tools are available. Qt uses native widgets on each platform. Qt is available for free for use on open source software (including KDE and the many KDE applications). For commercial use, it is less free:

$2000 per dev, for the “desktop light” edition (one platform)

$5000 per dev, for the “full” edition on 2 platforms

$more for various other packages

The QtRuby bindings are free, and described as “very complete”:

http://developer.kde.org/language-bindings/ruby/index.html

There is a book from the Pragmatic Press about QtRuby:

“Rapid GUI Development with QtRuby”

http://www.pragmaticprogrammer.com/titles/ctrubyqt/

Qt/QtRuby is very appealing, probably the most polished of all the options, except for the price. I believe the price will prevent large scale adoption. For those large corporate Ruby GUI projects, go with Qt.

Tk

Tk is in the Ruby “box” (installed by the installer, though I also saw instructions to install it separately), and has a complete, documented API. Unfortunately, it is also quite old and generally ugly; it seems more suitable for simple GUIs for utility programs, than for large, rich applications. However, this seems to be changing – the “Tile” theme engine for Tk greatly improves the appearance.

require ‘tk’

root = TkRoot.new

button = TkButton.new(root) {

text “Hello, World!”

command proc { puts “I said, Hello!” }

}

button.pack

Tk.mainloop

Win32

Also included in the Ruby installers are SWin and VRuby. SWin is a low level Win32 API binding, with VRuby is a GUI toolkit (OO wrapper) on top of that. VRuby appears to be inspired by Visual Basic or the Delphi VCL. Its controls are the Windows controls (including the TreeView and ListView), and are of course 100% native and 0% cross-platform. It uses a clever implicit event-binding technique, requiring generally 0 lines of code to bind an event to a method.

The documentation, while detailed, is in Japanese, and this is a relatively low-level toolkit, so it may be quite hard to adopt for non-Japanese speakers.

Update, January 2008: Anthony Leotta wrote in to point out that there is now good VRuby documentation, in English.

WxRuby / WxSugar

WxWidgets itself is stable, featureful, free, and used in many commercial applications. The most common way to use Wx appear to be with its native C++ API, and with WxPython. Wx uses native widgets for each platforms, and with a little work can have a modern slick look and feel.

http://www.wxwidgets.org

Unfortunately, the WxRuby bindings are incomplete and unstable – even the demo application crashed several times.

http://wxruby.rubyforge.org/

WxSugar adds a layer of “syntactic sugar” on top of WxRuby, to enable a more expressive, compact coding style.

http://wxruby.rubyforge.org/wiki/wiki.pl?WxSugar

Ruby Scripting for a non-Ruby GUI

Ruby can be used as an embedded scripting language; to do this, you’d write your application “core” in something else, then use Ruby for instance-specific business rules, plugins, etc. I demonstrated this last year at Code Camp with Lua, the same approach works well with other languages.

So What Do We Do?

I don’t have a single answer as to which of these to use; none of them has impressed me as a compelling replacement to the mature toolkits I’ve used, such as Java Swing (in the Java language, which for all its issues, is a good language to use for interacting with massive Java APIs).

Other References

Jeff Barczewski pointed out that the “Ruby Developer’s Guide” (a 2002 book by Michael Neumann), which features a free sample chapter on Ruby GUIs.

http://wiki.rubygarden.org/Ruby/page/show/ComparingGuiToolkits/TakeTwo

http://groups.google.com/group/comp.lang.ruby/msg/58504a6e39e6a1c7

http://www.trug.ca/Ruby_GUI_Toolkits

http://www.arachnoid.com/ruby/RubyGUIProject/index.html

http://www.trug.ca/VRuby

Ruby/TK tutorial: http://members.chello.nl/~k.vangelder/ruby/learntk/hello.html

8 thoughts on “Ruby GUI Toolkit Talk: Notes and Audio”

  1. Hello there!

    I’m curious, what would you consider “ready for prime time” as far as JRuby’s concerned? Feel free to say “1.0” and leave it at that, I know that’s many people’s metric, and it’s actually reasonably sound. But if there’s some other measure you’d use, I’d love to know it. There are lot of folks using JRuby in production today, for both Swing and server apps, and I think they all would say JRuby is ready. But I would love to know if there’s something specific you feel is missing…thanks!

  2. The book “Ruby Developer’s Guide” isn’t “upcoming; it was published in 2002.

    Just curious, when you say that FOX has a limited selection of widgets — what’s missing that you’d like to see? I know that the lack of an HTML display widget is often requested, but other than that omission I thought it had a pretty complete set.

  3. I attended Kyle’s GUI talk and am a big proponent of JRuby. That said, I think I agree with his assessment that JRuby isn’t “ready for prime time”. One of the reasons mentioned in the talk was that it seems new bugs are being added faster than they are getting resolved. I’m confident that it’s just a matter of time before that changes … maybe six months?

    Performance is a big issue for me. Many people feel that Ruby is slow. I can live with the speed of Ruby, but I’d like to treat that as the baseline of acceptable perfomance. I’ll feel much better about JRuby when its performance at least matches that of Ruby.

    Here are some examples of basic bugs in JRuby.

    require ‘java’
    list = java.util.ArrayList.new
    puts list.kind_of? java.util.List # returns false
    puts “list is a #{list.class.name}” # returns “”

  4. Charles: I updated the notesto show that my data was at of a few months ago. I haven’t kept up with JRuby development, so I don’t have specific on what things I’d consider important to fix before 1.0. I have some general thougths on the topic (but not specific to JRuby) in the audio of the talk.

    Lyle: Thanks, I have corrected the notes about the book and added a few more words about Fox. If I get a chance to dig in to Fox/FxRuby more (which seems possible – as I point out in greater depth in the audio of the talk, being “in the box” is a big plus for Fox/FxRuby), I’ll type up more detailed thoughts on the widgets.

  5. I layed out the printout with OpenOffice Writer, and printed them on my aging HP Laserjet 1100. I manually ran them through a second time to print on the back. The font is ordinary Times New Roman, built in to Windows.

    I did the work on my notebook PC, where I have OpenOffice but not MS Office. Word would have worked just as well.

  6. Kyle,

    I just finished listening to the audio.
    It was enjoyable and made me feel as if I didn’t miss the meeting :>
    It was kind of nice because as you all were discussing different libraries I was googling and checking them out myself.

    Thanks for providing it.

Comments are closed.