Part 2: Origins and general description of the environments

Due primarily to the greater power of the scripting languages, programs written with these tools are typically much shorter than equivalent programs writing in C or Pascal. This means that they take much less time to write and are easier to modify. Though class libraries and "component-ware" can be used to shrink the amount of code that needs to be written in a language like C++, programs written with these scripting languages will still be smaller in any non-trivial application.

Since the languages are interpreted, there is no compile-link-execute cycle and so development and debugging go much faster. Script execution errors are pointed out and can be fixed without exiting the environment. In most cases new code can be executed immediately. Though C-based environments can use tricks like precompiled headers and incremental linkers to reduce the compile-link cycle time, the fact that you have to restart your application from the beginning to test your new code remains a major disadvantage of developing graphical applications with compiled languages.

Another advantage of these tools is simplified access to the graphical controls. Instead of using complicated sequences of operations, you can get and set object properties with simple, single-line statements. The need to look up property names and the structures used to set properties is also greatly reduced, since the naming and argument passing conventions are simpler and more consistent between object types.

Their Rapid Application Development (RAD) capability make these tools especially useful for prototyping and developing applications that undergo frequent modifications. Combined with an Interactive Design Tool (IDT) for building the user interface, it becomes possible to have nonprogrammers prototype and customize applications, whereas they can only do the most rudimentary screen layout tasks with conventional Xt/Motif based GUI builders.

In many cases, even end-users can make simple modifications to applications, such as changing the layout or even adding buttons or fields, without requiring the assistance of a programmer. This is in striking contrast to most applications developed in Xt/Motif, where most end-users cannot even change the colors used in the application due to the overwhelming complexity of the X resource files used and the fact that the object-hierarchy is usually undocumented.

Though they are frequently dismissed as being "toy" development environments, Tcl/Tk, dtksh, and MetaCard are professional strength tools and are suitable for most, if not all, types of graphical application development. There are many commercial applications that are built in MetaCard and Tcl/Tk, and the number continues to grow as the tools become more sophisticated and as developers begin to accept them as viable replacements for conventional development environments. One big advantage of using these tools for commercial application development is that the pointer and memory leak problems that plague C and C++ programs cannot occur with these tools. As a result, applications built with them are more likely to be robust from their first release, whereas C applications are likely to need several patch releases to achieve the same level of reliability.

There are tradeoffs, however. Since the languages are interpreted, performance is always a concern. The languages also lack some of the features that make structuring large programs easier. These tools are also relatively new, and are still evolving to meet the needs of their users. This means that there are very few "gurus" who can teach new users how to use the tools and there is little third-party documentation and training available. Finally, at least for languages other than MetaTalk, debuggers, profilers, and other aids that are standard in more conventional environments are missing or still at an early stage of development.

Although tools in this genre are relatively new to the X Window System, they are already well established on the Macintosh and PC platforms. For example, HyperCard was released on the Macintosh in 1987. Since then, hundreds of thousands of people have used it to build custom applications. There are dozens of commercial applications that use HyperCard as a database environment, user-interface toolkit or as a help system, including one of the most popular computer games of all time: Myst. Visual Basic for Microsoft Windows also has an installed base in the millions and continues to grow in popularity. Microsoft has is now including a subset of Visual Basic in all of its productivity applications, replacing their application-specific macro languages. The result will be that millions of people will be using a general-purpose application development system to customize the applications they use every day.

While it might be tempting to equate these interactive GUI tools with C and Xt/Motif based User Interface Management Systems (UIMSs) such as UIM/X or TeleUse, there are several important distinctions that should be made. First, the interpreted languages used in these systems (C in the case of UIM/X and the proprietary scripting language 'D' in TeleUse) are designed to supplement the third-generation language code used to build the bulk of the application code, not to replace it. These tools are also not complete environments since must use compilers and other tools to build your applications. This increases development costs and results in applications that are not as easily portable as those built in dtksh, MetaCard, or Tcl/Tk. Finally, these tools are targeted at professional software developers, so they are much more expensive and usually much more difficult to learn to use than the interactive GUI development environments described here.

Tcl/Tk

As a language targeted at non-professional programmers, Tcl was designed with a simple syntax. It follows the "verb-arguments" design shared by MetaCard and many other scripting languages, though it does have some shell-like syntax requirements. For example, literals must be enclosed in quotes and variable references must be preceded by a dollar sign ($).

Tcl's most rapid growth has come as a result of the release of Tk (tee-kay), a toolkit that supports construction of graphical user interfaces using the Tcl language. Unfortunately, many shortcuts were taken in the design of Tcl and Tk due to the limited resources of the original development team:

The basic idea for Tk arose in response to Apple's announcement of HyperCard in the fall of 1987. HyperCard generated tremendous excitement because of the power of the system and the way in which it allowed many different interactive elements to be scripted and work together. However, I was discouraged. The HyperCard system had obviously taken a large development effort, and it seemed unlikely to me that a small group such as a university research project could ever mount such a massive effort. This suggested that we would not be able to particpate in the development of new forms of interactive software in the future. -- John Ousterhout (architect of Tcl and Tk)

Built on a custom toolkit written in C, Tk is gradually evolving toward full platform style-guide compliance. Even so, it is already close enough to Motif look and feel in the current version (4.0) that many users won't notice the differences. The look and feel on Windows deviates from the standard style to a greater degree.

Tcl/Tk does not come with an IDT. Although there is a freely available IDT for Tcl/Tk called XF, it is not part of the Tcl/Tk distribution and it is not used by most developers, the majority of whom still construct their user interfaces using hand-coded scripting language statements. In addition, XF has very limited direct manipulation abilities; it lacks the ability to graphically lay out controls, for example. It is better described as an "indirect-manipulation" tool since most object selection and manipulation is done with list boxes that contain the names of the objects, rather than with the objects themselves.

Sun has released a GUI builder for Tcl/Tk called SpecTcl that is of much higher quality than XF, but it is a commercial product and hasn't achieved widespread adoption by Tcl/Tk development community. Like XF, SpecTcl is not a full IDE as it lacks things like script editing and debugging tools.

Tcl/Tk is a sourceware package written in the C language. Potential users must get the source code (the anonymous FTP site ftp.cs.berkeley.edu is one source) and compile it on their systems before they can begin using Tcl/Tk. The advantage of this distribution method is that Tcl/Tk is very easy to extend, both by adding new commands to the language and by adding new display widgets. The latter is not usually required however, since Tk includes support for bitmap and object graphics, and has a powerful text widget that supports multiple fonts and hypertext links.

dtksh

When the COSE group was defining its standard desktop environment, it was recognized that an easy way to create graphical applications would be an important component of the environment. Therefore, the CDE specification included a "Dialog and Scripting Language" component. Though it would have been possible to use an existing Motif GUI tool like MetaCard or Tcl/Tk, the developers given responsibility for this aspect of the project decided to evolve wksh to meet the requirements.

Rather than starting with a clean slate, as is the case with MetaCard and Tcl/Tk, wksh was developed using two existing technologies: the Korn shell and the Xt/Motif toolkit. The advantage of this approach is that the underlying toolkits are robust and well-known. They are also quite broad since they have been extended over the years to solve a wide variety of problems. The disadvantage is that neither was designed to be particularly easy to use, nor easy to learn. In fact, due to backward-compatibility requirements, the basic structure of these components have changed only slightly over the years.

Like Tcl/Tk, dtksh interfaces are constructed by executing scripts. In in most cases these scripts are (will be) built by hand, rather than with an IDT since an IDT is not built in. Though some of the IDT/UIMS vendors have hinted that their tools will be able to output dtksh scripts instead of the usual C and UIL code, the current complexity and high cost of these tools ($3000-12,000) puts them out of the reach of most potential users of dtksh.

Since it is based on Xt/Motif, dtksh lacks built-in support for object graphics, and has only rudimentary text formatting features. To some extent these limitations can be overcome by using dtksh's ability to draw directly to the display using the lowest level Xlib calls, but the complexity of implementing drawing or painting functionality at this level is beyond the ability of all but the most experienced developers.

Adoption of dtksh has been slow in coming, probably due to the slow rate of adoption of the COSE desktop by the various workstation vendors. But presumably as the COSE desktop becomes more widely established, so will dtksh. At present, the only way to acquire dtksh is to acquire the COSE desktop from your workstation vendor (usually as part of an OS upgrade), or a third party such as TriTeal.

MetaCard

The MetaCard user interface looks and works like OSF/Motif on X11 system and like Windows 95 on Windows 95 and NT systems, but it is actually built with a custom toolkit written in C++. The user interface for MetaCard is itself written in MetaCard, so it can be customized by users to improve their productivity, or by developers to make it easier for end-users to customize their applications.

Unlike the other two environments, MetaCard has an IDT built in, making it by far the fastest tool with which to create user interfaces. The IDT was designed to be easy to use by non-programmers. In fact, it more closely resembles drawing program than it does most other IDTs. MetaCard's development environment also includes a graphical script editor and debugger, tools not included in the basic Tcl/Tk and dtksh packages.

Also unlike the other two environments, MetaCard applications are saved as binary files. As these binary files (called stacks) are read, they are converted directly into MetaCard objects. In contrast, with Tcl/Tk and dtksh an application's user interface stored as scripts. When an application is run, these scripts are interpreted to construct the interface. One disadvantage of this approach is that these script become quite long when construction large applications, making them more difficult to modify and maintain. It also makes producing GUI builders much more difficult, since it is necessary to intersperse calls to user functions with the code that generates the interface, making it difficult to regenerate the interface without overwriting the user functions.

Another disadvantage is that binary data such as bitmap graphics and audio clips must be stored in separate files from the scripts, whereas they can be stored directly in MetaCard stacks. Distribution of MetaCard applications is therefore much easier than for the other systems since in most cases only a single file needs to be moved.

The MetaCard binary format architecture also means that MetaCard objects are persistent. All of their properties, including the state of buttons and the text in fields is saved with the application. With the other two tools, if it is necessary to preserve the application state across uses of the application, scripts must be written to save this type of information to files and to read and restore the state from these files when the application is restarted.

MetaCard stacks can contain multiple cards, organized in a doubly-linked list. From a given card you can go to the previous card or the next card; stacks wrap around between the first and last cards. Since only the text in fields changes between the cards, the layout of the cards only has to be done once. This architecture can be used to easily construct address book-type applications, but can also be used to build documentation stacks where each card has a topic on it and the cards can be flipped like the pages in a book. For example, MetaCard's on-line documentation is constructed of MetaCard stacks. The user can use next and previous buttons to navigate through the topics covered in the stack. In addition, the MetaCard "find" command can be used to search all of the cards in the stack for a particular string. A third form of navigation is to use hypertext links. The user can click on a word and the card that has more information on that term will be opened.

MetaCard has built-in support for multimedia features such as video and audio playback. It also supports bitmap and vector graphics including the ability to edit both, making it a useful authoring and presentation tool in addition to a user interface development environment. MetaCard's text field control supports multiple fonts and sizes, alignment, subscript, searching and sorting, and hypertext links, making it easy to construct useful and aesthetically pleasing documents.

On to Architecture of the languages

Back to IDE Overview

Up to Table of Contents