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

Introduction

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

• Cross platform

Cons

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

FxRuby

Introduction

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

• 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

Introduction

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

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

Shoes

Introduction

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

• 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 all you want is to toss up the occasional message box, or ask a user for some simple input, almost any of the toolkits I've listed will do. For simple requirements, you are likely better off focusing on platform availability, a suitable range of widgets, and appropriate cost. If you plan to distribute your application, you'll want to check the toolkit licensing. You also must be sure either that the user already has the required environment or that you can easily bundle all the needed libraries and widgets in either a stand-alone application or an installation package. • Once you move to complex applications, though, the requirements get tougher. For any application that goes beyond a few simple forms, you almost certainly want to have a form-designer tool. You also want a rich set of available widgets; you're usually better off reusing an existing date picker or file browser component, for example, than writing your own. • Each of the various C-based Ruby GUI toolkits has its share of good qualities, but none of them has emerged as a clear winner. They offer no obvious choice for general Ruby cross-platform desktop development. To varying degrees, they all have issues with installation, documentation, design tools, packaging, and deployment. Notably, none of them can beat, feature-for-feature, the one non-C option.

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