CSC/ECE 517 Fall 2010/ch1 S10 MM

Introduction

A GUI toolkit is a set of widgets and APIs that can be used and extended to construct a graphical user interface application. At a minimum a GUI toolkit will provide generic graphical widgets to display to the screen, and an eventing system to tie interactive widget pieces with other widgets, or to a data model. Most toolkits will provide widget containers for easy layouts, abstract data model types and containers, and an easy to use mechanism for implementing an observer pattern for linking widgets and data structures. Advanced toolkits, such as Qt, will even offer convenience widgets for advanced data display, concurrent programming abstractions, or even a whole browser backend (based on Webkit, in Qt's case). Ideally a toolkit would work across several different operating systems with very minimal changes to the application code or compilation process.

Most GUI toolkits are natively composed in C++. Object-oriented language features are all but required for the level of base functionality extension required in a large GUI systems. In many cases, though, bindings for the toolkit will spring up in different languages, and usually the most useful bindings will be in a dynamic scripting language such as Python, or Ruby. This page will talk about several GUI toolkit bindings in the Ruby language.

Dynamically typed languages offer many different advantages for GUI development. Since GUIs typically work with many different simple and composite data types, and the toolkit itself adds a large number of class types on top of that, defining class interfaces and usable data structures, and making them available to the right widgets at the right time within the application can be tedious in statically typed languages. Dynamic languages offer the ability to define, and redefine these things, allowing very rapid development.

The only downside to coding with the dynamic languages is that the speed of the application will suffer due to interpreter overhead, but even for large applications this may be acceptable if the application does not require a particularly high frame rate under heavy load. Logistically, however, in many cases there are problems with the level of support and maintenance in a particular binding project. It is always useful to look at when the last version control checkin was made for a project if that is available, and try to compare the latest binding release date with the latest native implementation release date. Also, it is usually harder to find documentation for the specific dynamic language that you are using, and you may be stuck reading C++ API documentation, and potentially source code for the project when you hit something you did not expect. There are also usually slight complications with deployment, and there may be licensing discrepancies between the C++ and Python/Ruby versions as well.

Other GUI toolkits

• FXRuby
• Ruby-GNOME2
• Shoe

References

• General:

| Language Bindings

• Ruby/Tk:

| Ruby/Tk

• wxWidgets and wxRuby:

| wxRuby

• Qt and QtRuby:

| Qt Homepage | Qt Documentation | QtRuby

• Comparisons: