Graphical User Interface Evaluation

Dhiman Chakraborty,David Adams, Lee Lueking,Nobu Oshima, Mike Shupe, Scott Snyder

1. Introduction

There will be many Run II graphical user interface needs in D0 and there exist many options for implementing solutions. These options have widely varied requirements for programming skill, product performance and functionality. An array of tools exists for creating simple menu-type GUIs using a number of simple languages genericly referred to as "scripting" languages, these are attractive and may fulfill the needs of many of our applications. It is clear that there will be Web-based GUIs which will provide information about the operation of various systems and data processing and access in the experiment and these needs might best be served by recently developed technologies which provide a range of tools specifically targeted at such problems. Some of our applications may prove too complex for simple solutions and may require detailed knowledge of more intricate lower level tools, such may be the case for some on-line applications and possibly specific off-line areas, such as event display.

It is assumed that the audience for the solutions explored is comprised of physicists with some computing specialists who help write and maintain the procedures. A primary goal is to provide an environment which will enable everyone using D0 applications and resources quick and easy usage, with clear and intuitive menuing presentations. This is as an art, and attention needs to be paid to such things as location of menu items, standard shortcut keys, mouse-button convention, et cetera. It should be possible for anyone, regardless of experience, to sit down at a D0 tools web page and work his/her way into almost any application and access information about on/off -line systems, code libraries, data taking and processing.

Our criteria for the tools which we use are dependent on the application, but in general we will need: 1. ease of use, 2. ease of programming, 3. UNIX and windows platform independence, and 4. longevity. Ease of use means that the GUI menues should be easy to understand and manipulate. Ease of programming includes issues related to creating the code or scripts which generate the interfaces and or manage the information which they provide. This is particularly important for applications which will involve scripting languages, since the choice of language will affect other areas, such as frames, and possibly many issues of d0 daily life. Choosing a scripting language which is easy to write, read and debug is important. Also, if the language is useful, some very large applications may emerge once people learn how to use it effectively and thus, a full featured language is desirable. Since we know we will have both UNIX and windows clients, it is important to maintain a set of platform independant tools. Finaly, we are looking for solutions which will be with us for several years throughout the Run II period. To find solutions with longevity is difficult in an age when new technologies appear and disappear almost overnight.


With this in mind, lets look at a few defining examples. These were chosen from the main areas in which GUIs will be used. They may not represent the full range of applications, but clarify specific features which are required.

2. Solutions

There are several closely related domain areas involved in the field of GUIs. At the heart of the interfaces in which we are interested is probably X/Motif. This is compliant with the X protocal and can be displayed on all of the graphics devices we use, including workstations, PCs, and X-terminals. However, programming in X/Motif requires expertiese and time beyond what most of us would like to invest, so there are some compromise solutions. In the world of GUIs, the display components which are used to construct the overall product are genericly called "widgets". There are extensive libraries of widgets available, many written in c, but still not that easy to use.

One appealing solution which has been widely adopted is the use of simple languages referred to as "scripting languages" which have been interfaced to widget libraries or windowing toolkits. The list of such languages is endless, but there are a few which are commonly used and provide the features which we need. At the high end of graphics, there are integrated tools such as Open Inventor which provide an environment tools for putting together control boards used for manageing the windows which run within the context of the application. For most of our needs, these are too complicated, but might be a logical way for dedicated graphics applications, such as the event display, to proceed.

2.1 Scripting Languages

There are several interesting options for scripting languages, and some are so complete that they are real programming languages. There are many considerations which we kept in mind while performing the evaluation. How complete are library extentions? How rich is the development environment, like debuggers and class brousers. How much will it cost? Would it be easily extensible or scale up to larger applications? How will it interface to the many applications which we may be using at D0? How easy is it to write? How easy is it to read code written by someone else?

We examined four such languages; 1. TCL, 2. Perl, 3. Python and 4. Java . Below descriptive information, stolen from theweb, is included for each of these. There are others like Lisp, Scheme,et cetera but the ones below seem to be widely accepted and used in applications such as ours. The first three offer interfaces to a widget toolkit called "tk" which was first packaged with the TCL language and was a major selling point. Java does not yet hava tk interface but there is an alternative package called the Abstract Windowing Toolkit ,AWT, which comes packaged with it as well as others in the works.

2.1.1 TCL


Tcl, pronounced tickle, stands for the Tool Command Language. With its associated user interface toolkit, Tk, pronounced tee-kay, you can quickly create cross-platform applications. The latest news in the Tcl/Tk community is the final release of Tcl 7.5 and Tk 4.1. These are the first releases to officially support Windows and Macintosh platforms, in addition to Unix. Created by John Ousterhout, now working at Sun Microsystems, Tcl is more like a scripting language than a programming language, so it shares a greater similarity to the C shell or perl than it does to C++ or C. For example, the following is the Hello World program in Tcl/Tk:

button .b -text "Hello World" -command exit pack .b 

Tcl has a simple structure. Each line starts out with a command, such as button and a number of arguments. Each command is implemented as a C function. This function is responsible for handling all the arguments. Tcl commands can span multiple lines through the use of a line continuation marker, \, or curly braces, { and }. You can create your own commands in C or you can use the Tcl proc command to create procedures written in Tcl. Some key features of Tcl include:

When Should You Use Tcl? For more information on when to use Tcl and when to use other languages, such as perl, see the Comparisons of Tcl with other systems page, which contains quite a lot of comparisons of Tcl with languages like perl and Java. Running Tcl Programs Since Tcl is an interpreted language, to run a Tcl program (also called a script), you normally pass the script file to the Tcl interpreter, wish, for example: wish hello.tcl You can also use wish in interactive mode and type in commands at the command line. There's another standard Tcl interpreter, tclsh, which only understands the Tcl language. tclsh does not have any of the Tk user interface commands, so you cannot create graphical programs in tclsh. Some Tcl freeware applications extend the Tcl language by adding new commands written as C functions. If such is the case, you need to compile the application instead of just passing its Tcl code to the wish interpreter. This application program, from a Tcl perspective, is really a new version of the wish interpreter, which the new C commands linked in. Of course, the application program may be a lot more than merely a Tcl interpreter. (Note: you can also use Tcl's auto-loading capability on systems that support it.)

Since Tcl is so easy to extend, many try to share extensions, including the popular itcl, [incr Tcl], ObjectTcl, TclX, Tix and BLT. Before using any of these extensions, be sure to check the license agreement. Tix, for example, is becoming a commercial product and will be free only for non-commercial use. These extensions, of course, require an extended Tcl interpreter. In addition, many Tcl freeware applications require a particular Tcl extension to run. One very popular extension is called Expect, which allows you to place a friendly front-end onto most command-line based Unix applications, such as telnet, ftp, passwd, fsck, rlogin, tip and so on.

2.1.2 PERL


Here's the beginning of the description from the man page: Perl is an interpreted language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. It's also a good language for many system management tasks. The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal). It combines (in the author's opinion, anyway) some of the best features of C, sed, awk, and sh, so people familiar with those languages should have little difficulty with it. (Language historians will also note some vestiges of csh, Pascal, and even BASIC-PLUS.) Expression syntax corresponds quite closely to C expression syntax. Unlike most Unix utilities, Perl does not arbitrarily limit the size of your data--if you've got the memory, Perl can slurp in your whole file as a single string. Recursion is of unlimited depth. And the hash tables used by associative arrays grow as necessary to prevent degraded performance. Perl uses sophisticated pattern matching techniques to scan large amounts of data very quickly. Although optimized for scanning text, Perl can also deal with binary data, and can make dbm files look like associative arrays (where dbm is available). Setuid Perl scripts are safer than C programs through a dataflow tracing mechanism which prevents many stupid security holes. If you have a problem that would ordinarily use sed or awk or sh, but it exceeds their capabilities or must run a little faster, and you don't want to write the silly thing in C, then Perl may be for you. There are also translators to turn your sed and awk scripts into Perl scripts.

Perl, the practical extraction and report language, has captured the hearts and minds of computer users everywhere. So much, so, in fact, that some people go so far as to write poetry in perl, taking advantage of perl's confusing syntax. (Perl is also called the pathologically eclectic rubbish lister.)

Perl is a very flexible scripting language. Originally designed for Unix system administration tasks, perl has branched out to tens of thousdands of users and millions of uses. Some of the main uses include:

2.1.3 Python

(from )

Python is a portable, interpreted, object-oriented programming language developed over the past five years at CWI in Amsterdam. The language has an elegant (but not over-simplified) syntax; a small number of powerful high-level data types are built in. Python can be extended in a systematic fashion by adding new modules implemented in a compiled language such as C or C++. Such extension modules can define new functions and variables as well as new object types. Here's a simple function written in Python, which inverts an table (represented as a Python's dictionary): def invert(table):

index = {} \# empty dictionary for key in table.

Note how Python uses indentation for statement grouping. Comments are introduced by a `\#' character. Here's an example of interactive use of this function (">>> " is the interpreter's prompt):

>>> phonebook = {'guido': 4127, 'sjoerd': 4127, 'jack': 4098} 
>>> phonebook['dcab'] = 4147 \# add an entry 
>>> inverted_phonebook = invert(phonebook) 
>>> print inverted_phonebook {4098: ['jack'], 4127: ['guido', 'sjoerd'], 4147: ['dcab']} 

Python has a full set of string operations (including regular expression matching), and frees the user from most hassles of memory management. These and other features make it an ideal language for prototype development and other ad-hoc programming tasks. Python also has some features that make it possible to write large programs, even though it lacks most forms of compile-time checking: a program can be constructed out of a number of modules, each of which defines its own name space, and modules can define classes which provide further encapsulation. Exception handling makes it possible to catch errors where required without cluttering all code with error checking.

A large number of extension modules have been developed for Python. Some are part of the standard library of tools, usable in any Python program (e.g. the math library and regular expressions). Others are specific to a particular platform or environment (e.g. UNIX, IP networking or X11) or provide application-specific functionality (e.g. image or sound processing). Python also provides facilities for introspection, so that e.g. a debugger or profiler for Python programs can be written in Python itself. There is also a generic way to convert an object into a stream of bytes and back, which can be used to implement object persistency as well as various distributed object models.

2.1.4 Java


Java has caused more excitement than any development on the Internet since Mosaic. Everyone, it seems, is talking about it. Unfortunately very few people seem to know anything about it. This tutorial is designed to change that. People are excited about Java because of what it lets them do. Java was the first way to include inline sound and animation in a web page. Java also lets users interact with a web page. Instead of just reading it and perhaps filling out a form, users can now play games, calculate spreadsheets, chat in realtime, get continuously updated data and much, much more. Here are just a few of the many things Java can do for a web page: Inline sounds that play in realtime whenever a user loads a page Music that plays in the background on a page Cartoon style animations Realtime video Multiplayer interactive games

However Java is more than just a web browser with special features. All of these features can be integrated into browsers in other ways. Although HotJava was the first browser to include inline sound and animation, Microsoft's Internet Explorer 2.0 and Netscape Navigator 2.0 support these features in several different ways. What makes Java special? Java is a programming language for distributed applications. It doesn't just allow you to add new types of content to your pages like Netscape and Internet Explorer do. Rather it lets you add both the content and the code necessary to interact with that content. You no longer need to wait for the next release of a browser that supports your preferred image format or special game protocol. With Java you send browsers both the content and the program necessary to view this content at the same time!

Let's think about what this means for a minute. Previously you had to wait for all the companies that make the web browsers your readers use to update their browsers before you could use a new content type. Then you had to hope that all your readers actually did update their browsers. Java compatibility is a feature that any browser can implement and by so doing implement every feature! For instance let's say you want to use EPS files on your Web site. Previously you had to wait until at least one web browser implemented EPS support. Now you don't wait. Instead you can write your own code to view EPS files and send it to any client that requests your page at the same time they request the EPS file.

Or suppose you want people to be able to search your electronic card catalog. However the card catalog database exists on a mainframe system that doesn't speak HTTP. Before Java you could hope that some browser implemented your proprietary card catalog protocol; (fat chance) or you could try to program some intermediate cgi-bin on a UNIX box that can speak HTTP and talk to the card catalog, not an easy task. With Java when a client wants to talk to your card catalog you can send them the code they need to do so. You don't have to try to force things through an httpd server on port 80 that were never meant to go through it. If that were all Java was, it would still be more interesting than a tag in some new browser beta. But there's a lot more. Java is platform independent. A Java program can run equally well on any architecture that has a Java enabled browser. With the release of Netscape Navigator 2.0 that includes Windows 95, Windows NT, the MacOS, Sun Solaris, Sun OS 4.1.3, SGI IRIX, OSF/1, HP-UX with more to come. But wait. There's more!

Java isn't just for web sites. Java is a programming language that lets you do almost anything you can do with a traditional programming langauge like Fortran or C++. However Java has learned from the mistakes of its predecessors. It is considerably cleaner and easier to use than those languages. As a language Java is:

2.2 Graphics widgets for menus, etc.

Labels, buttons checkbuttons, radio buttons, Iconic buttons, image viewer, list boxes, entries with and without scrollbars, canvases, linear scales, thumbwheels, pulldown menus possibly with cascades; these are amont the many terse terms used to describe various types of interface objects collectively called "widgets". The toolkit (tk) provided by John Osterhaut provides a broad array of these widgets and has been integrated for use in most of the popular languages, as described above. Other languages, such as Java, have libraries of their own. In addition, there are sources of free and commercial widgets which provide neat and extended features which we might like at some point. There is,for example, a source called the Free Widget Foundation which is similar to the Free Software Foundation and maintains a selection of free widgets.

Following are illustrations of a few of the more popular types of widgets. Most of the examples are from tk, although the thumbwheel and thumb index are from other sources as nothing like them is included in tk.

2.2.1 Buttons (example from tk)

2.2.2 Check Buttons

2.2.3 Radio Buttons

2.2.4 Iconic Buttons

2.2.6 List Box

2.2.7 Entry Box

2.2.8 Canvas

2.2.9 Vertical Scale with Slider

2.2.10 Horizontal Scale with Slider

2.2.11 Thumb Wheel and Tab Index

3. GUI Event Handling

In GUI talk, whenever the user provides input information to the GUI and something is supposed to happen, an "event" occurs. The input information can be in the form of clicking a mouse button, or typing a letter or series of letters, hitting a particular key et cetera. There are two main methods employed for event handling : 1. call back and 2. event polling. In the case of call back, each particular type of event triggers a call to a procedure, or method which then causes the desired effect. In the case of event polling, a loop is established which continually checks if an event has occurred and,if it has, then the proper action is taken. In complex applications, such as event display, events may occur in many different "parts" of the program, where each "part" might represent the main GUI or various display processes. Either some method is required for the various processes to communicate or, they must behave independantly from each other. Can a tight connection be allowed between mouse and keyboard actions and the graphics routines which need the information "instantly"?

There are two extreme program configurations we might keep in mind which help clarify these issues:

4. Other Considerations

4.1 Graphics Interfaces

The use of a script language and tk will satisfy a broad set of needs for GUI's, However there may be other areas which require a graphics interface at a different level. Some examples which we considered, in passing are:

Some of these are being pursued by other groups or could be explored in more detail if needed.

4.2 Web interfaces

There will be a need to interface many of the GUI applications which we develop to the Web. Convenient interface tools exist for many languages called Common Gateway Interface or CGI language. For Java, there are many network tools availablle under

4.3 Other types of interaction

In addition to the areas which we explored there are other multimedia areas which may be of interest for certain areas, for example annimation and sound. These are available but may complicate the hardware requirements needed by applications.

5. Recommendations based on current experience

After examining the various options for only a few weeks it is not completely clear what the correct solutions may be. However, there seem to be some outstanding options. For most of the applications, the scripting language with tk option seems to provide the most flexible solution. There are varied opinions concerning which anguage is best and it is good to have so many workable options from which to choose. The tk graphics tool kit is very attractive and all of the languages which we examined, with the exception of Java, have interfaces to this. So, let's look at how the various language options stack up against one another.

TCL- Our general sentiment is that TCL is too confining for our purposes. The following was extracted from "Why You Should not use TCL" by Richard Stillman - GNU Project and expresses many of our concerns:

PERL - Perl is liked by those who use it and it is a powerful tool for many jobs. It provides extensive tools for string manipulationan and has a very convenient set of system interface tools on Unix. It has been used extensively in industry for over 5 years and has been used for several large applications in the run I data processing. The latest version of perl, perl5, is "object-oriented" and cleans up many of the features which were difficult in the previous versions. It is felt,however, that its syntax is cumbersome and difficult to read. This may be a problem for scripts which may have many authors and are not as well documented as we would like.

PYTHON - Python is an attractive candidate for our scripting language. The frames group has been working with it and feel that it fits nicely into their approach. Python is considered a language which has a broad dynamic range i.e. one can begin programming very simple scripts after only a brief introduction to the language but, experienced Python users can employ all of the features of the language to build very complex and extensive scripts. Its object-oriented features are very functional and make it very powerful. Python is very good for scaling from small to large projects, partly due to its being intrepreted, which encourages users to play with small pieces of a program and then pack things into modules which are "reusable".

The main concern about using python is support. It is not clear how many python users exist and it seems to have not been embraced by the computing community to the extent of the other languages. Many questions exist. Will it be ported to new platforms in the future? Will Fermilab even support python as a product? If not, maybe we should think hard before using it.

JAVA- Java is considered an extremely interesting option but it is a quickly moving target. For some of our applications, especially web-based ones,it may be ideally suited. There are extensive development environments available on many platforms and many software providers are embracing it whole heartedly. There may be Java bindings for many popular database vendors and thus it may provide a straightforward way to provide such information to users.

However, it seems to have several drawbacks. First of all, it is a byte-code compiled language, which means there is an intermediate step between writing the code and using it. This compromises one of the primary reasons we started looking at this type of language in the first place. An interpreted language tends to make coding easier and turn around faster. Secondly, it is a more "closed" environment than the other options. In the case of TCL,perl and Python, the source codes of the intrepreters are freely available and modifying or adding features or "verbs" is possible. The security features which are built into Java may make embedding it in c or c++ difficult, which would be incompatible with our needs. It is also not clear what the real cost might be for Java. Although the development tools are nice, they are not generally free.

6. Future Goals and Directions

To fully evaluate this area we plan to create prototype interfaces for a couple of applications. While pursuing this, we may attempt to do this in a couple of different scripts, say perl and Python. This will give some additional feel for the types of difficulties encountered in each. Here are a couple of examples:

We also need to consider in more detail other examples.There may be instances which the scripting language solution does not fit, and a full blown X/Motif effort is required. We hope these cases are few, but we willl learn with more experience. We will also keep our "ear to the rail" for new attractive solutions.