CSC/ECE 517 Fall 2010/ch1 S10 PH

Overview

When starting to build a new desktop application, we all have to make a very important decision regarding which GUI toolkit to use from a pool of so many available. In very simple words, a Graphical User Interface (GUI) toolkit is the set of API's (Application Programming Interface) that produces the graphical user interface your users will interact with. There are a number of factors to consider when choosing the toolkit. Different toolkits support different platforms (Linux, Windows, OSX) and have different features such as accessibility, layout engines, and looks. We will see all these considerations with respect to Ruby in the sections below.

GUI Toolkits for Ruby

Ruby is an Object-Oriented Programming language. Till very recently, what could have been considered its most usable implementation was the open source interpreter. The way Ruby was designed,Ruby did not have very interactive capability other than just accepting text inputs on a console. Basically any editor could be used to develop programs in Ruby. A thing to be noted is that the freshly installed Ruby interpreter is not integrated with any one development environment.

At the onset of year 2009, Ruby was not well known for being used for developing regular or commercial desktop applications. A possible reason was identified as a lack of good GUI-related libraries. Although, Tk, which is packaged in Ruby's standard library, can be used to develop desktop applications, it is considered disorganized and the API is considered to be from yesteryears.Things evolved and today we have the developments of number of third party libraries like FxRuby,WxRuby,QtRuby,GTK-Ruby,Shoes and Swing which give Ruby graphical user interaction (GUI).These libraries give Ruby the user interface elements like text boxes to key in data, buttons to perform certain operation and window displays. More recent alternate implementations of Ruby have their own GUI facilities, such as Cocoa for MacRuby and Swing for JRuby. These toolkits are not really brand new but some like FxRuby, wxRuby, ruby-GNOME2 and RubyQt are simply wrappers for toolkits written in C or C++ .Shoes is a graphical library is implemented for Ruby alone.

All the toolkits have some common features but they also differ in many aspects. There is no “best” toolkit in abstract terms.The usefulness of a library is only really tested by trying to use it to perform a specific task. Similarly, the toolkit shortcomings may only become apparent after a using it in substantial and a purposeful way.

Developing a GUI library for Ruby is actually time-consuming. There are many reasons for this like, the large number of classes and methods often involved in the implementation; the need to employ lower-level compiled languages;cross-platform support;automated testing; highly variable paths through code; and the complexity of reconciling Ruby's GC-based memory management with that of the base language (often C or C++) in long-running applications.

Ruby's popularity has double folded in recent years.It remains a small language when compared to C, C++ and Java and hence tt is an open question whether having a large number of libraries that more or less provide similar features is an optimal outcome.

Tk

The standard graphical user interface (GUI) for Ruby is Tk. It was initially developed for the Tcl scripting language by John Ousterhout. To install Ruby from source code, you also need to have the Tk dependencies and and compilation settings need to include Tk. If you install Ruby on Windows using the 'one-click' installer package, you will be required to take extra steps to have Tk working, because automatic installation is no longer supported. Even with Tk set up for Ruby it is not that easy to use. Tk applications really do not have a good look-and-feel and trying to create complex interfaces can get troublesome. Tk is best used for smaller GUI needs.

Pros & Cons

Pros -

• Cross platform

Cons -

• Badly documented
• Not elegant
• Widgets are non-nativ

FxRuby

FxRuby is a based on Fox which is a GUI toolkit written in C++. It can be installed using RubyGems. A binary gem is available for Windows. The gem for other platforms requires you to compile native code.

Pros & Cons

Pros -

• Book available for reference

Cons -

• Binary gems are available for Windows, OS X, and Ubuntu Linux but for other platforms,for installing the gem you need to compile native code.

WxRuby

WxRuby is a binding for the cross-platform wxWidgets C++ GUI toolkits. This lets you create native-looking desktop applications. It is available for installation as a gem.

Pros & Cons

Pros -

• Cross platform
• Larger support community
• Windows support
• Ease of installation
• Comprehensive widget set
• Internationalization
• Liberal licence

Cons -

• Cons of wxRuby

QtRuby

Provides Ruby bindings to the Qt toolkit. This is used in the he KDE desktop system.

Pros & Cons

Pros -

• Book for reference available.
• Native looking desktop applications can be created
• Available as a Gem.

Cons -

• Even though a gem is available for the Windows installation, for other platforms, only source code is available.

Shoes

Shoes is a very recently introduced Ruby GUI widget. Shoes was designed specifically for Ruby unlike the other toolkits which were first developed for C/C++ developers. Installing Shoes is very easy and it has packaged set-ups for every platform. Shoes is not really designed for serious,large-scale application but you can write small and useful programs using Shoes. The learning curve for Shoes is very small.

Pros & Cons

Pros -

• Good graphics
• Easy control at a lower level
• Simple interface with redistributables and examples

Cons -

• Considered rough around the edges since it attempts to support so many platforms
• Lacks many of the more robust widgets common in other toolkits

Comparison of various GUI toolkits for Ruby

Best GUI Toolkit for Ruby Survey 2008

Towards the end of year 2008, a survey of Ruby programmers was conducted.This set of respondents had those who had never done GUI programming in Ruby, those who had done some Ruby GUI programming in the past but now were not doing so and those who are doing so presently. This survey aimed to find the use and their attitudes towards graphical user interaction (GUI) libraries used for creating Ruby desktop applications.Here are the summarized results to get an insight into what were the most important features programmers looked for:

• The Ruby GUI "scene" remains fragmented: the survey found at least a dozen separate GUI libraries in current use. The most used toolkits were Shoes (21%), Ruby-GNOME2 (19%) and wxRuby (16%).

• Of users naming a single preferred toolkit, Ruby-GNOME2 and Shoes were chosen by 26%, wxRuby by 17% and RubyCocoa 11%; no other toolkit received more than 10%.

• There are striking differences between Japanese and Euro-American Ruby users. Among Japanese Ruby developers, Ruby-GNOME2 is the preferred toolkit of a majority (56%), whereas among Euro-Americans, it lies third behind Shoes and wxRuby in popularity

• Preference for one or other of the two leading comprehensive toolkits (GNOME2 and Wx) is not strongly predicted by the general importance attached to features of GUI libraries. This suggests their capabilities and range of potential applications largely overlap

• The emergence of new Ruby implementations and their associated GUI options has already had an effect on usage. MacRuby/Cocoa and, to a lesser degree, JRuby/Swing are well used and well regarded. MacRuby/Cocoa was the highest rated among all options for how well it met users' GUI development requirements.

• Ruby-Tk received the worst rating for how well it meets users' GUI requirements, with a modal rating of 'poor'. It was the only library for which fewer respondents said they planned to use it in the future than are currently using it. It seems its continued inclusion in the standard library is unjustified.

• Among those with an opinion, there's a 60/40 split against including any GUI library in the Ruby standard distribution.

• The high degree of fragmentation has not served potential GUI developers well. Almost all see Ruby as a viable GUI programming language, but the immaturity of the toolkits is the commonest reason for not using Ruby for GUI work. The means of redistributing ruby GUI apps to end users is another obstacle.

The numbers above clearly demonstrate that GUI library usage in Ruby remains highly fragmented. The most widely used library, Shoes, is currently being used by less than one in four GUI developers. They also suggest that this fragmentation is likely to persist. However, the the relatively new options, such as JRuby + Swing, MacRuby and Shoes, and the relatively low usage of long-established libraries such as FxRuby and Qt, are an indication that the situation is labile. It's a poor showing for the “standard” Ruby library, Tk, it being the only one where fewer users expect to use it in the future than are using it now.

Patterns of preference broadly follow patterns of usage, and most of the same comments apply. There was a very strong relationship between mother tongue and preferred toolkit. Among Japanese Ruby developers, Ruby-GNOME2 was the preferred toolkit of an absolute majority; among speakers of European languages, the same toolkit was less popular than Shoes and wxRuby. This is almost certainly a reflection of the language of the lead developers of each of those toolkits: Japanese for GNOME2, English for Shoes and wxRuby. If the lead developers speak the developer's language, this is likely to furnish more documentation and timely community support in that language. This is a nice example of the significance of non-technical factors in toolkit selection.

When to use what

If you just want to make a message box pop-up occasionally, or ask a user for some simple input, then any of the toolkits will work well.

You may decide to take into consideration characteristics like platform availability, a suitable range of widgets, and appropriate cost if your application requirements are really simple.

For distributing your application, you will need to look into toolkit licensing issues. You will also have to take into consideration whether the user already has the required environment or you will have to create an installation package for all libraries and widgets needed.

For complex applications, which consist of more than a few simple forms, you will definitely require a form-designer tool. You would also need a rich and varied set of available widgets. Instead of re-inventing the wheel, it is better to use or rather re-use an existing component like a date picker or file browser rather than writing your own.

Selection Criteria of GUI toolkit

• Ease of distributing applications
• Web-based documentation
• Availability on multiple platforms
• Maturity / stability
• Appearance / aesthetics
• Nonrestrictive license
• API programming style
• Ease of installation
• Rich set of widgets or components
• Community support/Whether or not it is actively maintained
• Speed / performance
• Internationalization support
• Licence compatible with commercial use
• Accessibility features
• Availability of extra tools
• Familiarity of toolkit other languages
• Paper-based documentation
• Solid implementation
• Ease of creating custom widgets
• Affordable cost
• Existing frameworks and libraries to speed development
• Mature IDEs and form layout tools
• Testing tools and frameworks
• Ease of packaging and deployment

References

1. Cache coherence
2. Introduction to QuickPath Interconnect
3. CMP Implementation in Intel Core Duo Processors
4. Common System Interface in Intel Processors
5. Cache consistency with MESI on Intel processor
6. AMD dual core Architecture
7. AMD64 Architecture Programmer's manual
8. Software Optimization guide for AMD 10h Processors
9. Architecture of AMD 64 bit core
10. Silicon Graphics Computer Systems
11. Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta
12. Three state invalidation protocols
13. Synapse tightly coupled multiprocessors: a new approach to solve old problems
14. Coherence protocols: evaluation using a multiprocessor simulation model
15. Dragon Protocol
16. Xerox Dragon
17. Coherence Protocols
18. XDBus