Before I began to work on TPF/GI—the graphical user interface for CMSTPF—I had never heard of the TPF operating system. I was unfamiliar with the EBCDIC character set. I had only a theoretical knowledge of big-endian byte order. And, worst of all, I was totally ignorant of the fact that a black background with green characters was the way God intended humankind to view information.

In other words, I did feel some culture shock. But fortunately the experts at TPF Software helped me over the rough spots so that we could start to make decisions about how to recast CMSTPF, the TPF testing and debugging tool, in GUI terms.

How do you take a command line application and make it graphical?

This article is about a few of the ways we answered that question as we designed the TPF/GI user interface. If you’re doing some TPF-to-GUI work yourself, you may find these decisions interesting. As a bonus, if you are a new or less-experienced user of TPF/GI, this article may point out some landmarks that help you get oriented in the TPF/GI environment.

If you’re moving a command-line application to the GUI world, does the command line have to be eliminated? We decided it did not—that we wanted to make the command line unnecessary, but keep it available. Here’s why.

First of all, CMSTPF has placed a rich set of commands at the user’s disposal, and although the most important of these were to be represented in the GUI right away, creating an interface for all of those commands was going to take some time. Keeping the command line around would help us make the transition.

Secondly, we decided users might need the command line around to help them make the transition. Power users of CMSTPF can type 23 characters and press Enter in the time it takes you or me to double click the mouse; because they are so proficient with commands, they may never completely give up them up. In a similar vein, we felt that novice users might be more comfortable with TPF/GI at first if they were able to type in a few of the CMSTPF commands they had already learned.

That’s not to say we didn’t GUI-ize the command line. Figure 1 is a screen shot of our TPF/GI Console. At the bottom of the window in Figure 1, you can see the "combo box" where the user types commands. A combo box is a combination of an edit box and a drop down list; in this case, that drop-down list is a retrieve list of old commands. This drop-down list allows the user a convenient and visual way to select an old command to repeat.

Figure 1: The TPF/GI command line window incorporates GUI features.

The button in the bottom left corner of the window lets the user start and stop logging. And the scroll bar, another GUI element, allows the user to scroll back and see previous results.

The last thing to mention is that because the TPF/GI console is in its own "window," it can be moved and resized independantly of other elements in the program—a huge benefit of GUIs.

What our experience with the TPF/GI Console suggests is that even when you keep supposedly "backward" elements in your GUI implementation, such as a command line, the "backward" elements gain in power and expressiveness in unexpected ways.

While keeping command line elements can make users more comfortable, fitting in with the Windows environment can be just as important. Face it: most TPF programmers have also become daily Microsoft Windows users, and they expect Windows programs to behave in certain consistent ways.

Figure 2: The TPF/GI file open dialog looks like the normal Windows file open dialog.

One area in which we went to quite a bit of trouble to fit in with Windows was in our file open dialog box (Figure 2). You can see that it looks exactly like a standard Windows file open dialog, with a drop-down box to specify the disk or drive, a central area to display the file names, and so forth.

Windows supplies a standard file open dialog box that most PC applications can call on, but because our users need access to the CMS file system as well as the PC file system we had to create our own dialog box, with our own underlying code for updating the list of files and disks.

Since we were starting from scratch, we could have created any interface we wanted for file transfer. Still, we duplicated the look and feel of the Windows file open dialog in order to ease user acceptance of our application and reduce training time.

The most interesting design work in a TPF-to-GUI project involves representing distinctly TPF structures in a graphical way. Your hope as a designer and coder is that your interface makes the underlying structure more accessible and usable than it ever was in the command-line environment.

One effort we’re proud of in this regard is our graphical ECB window (Figure 3). The ECB window is divided into several pages. By clicking a tab at the top of the window, a user can have instant access to the EBW area, the EBX area, the Level area, and so forth. The data in these areas can be edited, and the areas are updated live when the user steps through a TPF application program.

But the ECB page we’re proudest of is the "Graphical" page. This page shows the register values and the most recent machine instruction lines, and it shows graphical depictions of the program nesting levels, the data levels, and other information—all in one snapshot.

The graphical data levels are particularly interesting from a user interface standpoint. They change from blue to red to indicate that a core block is associated with the data level. In addition, an inset red block—you can see this in data level 5 in Figure 1—alerts the user to the presence of one or more detached blocks.

In terms of GUI idioms, we pulled out all the stops with the graphical ECB. To get core for a data level, the user simply drags the little memory chip icon and drops it on a data level. To release core, the data level is dragged to the small trash can icon and dropped. These commands are also available by clicking the right mouse button on any data level. and selecting the command from a popup menu.

To the greatest extent possible, a truly graphical interface allows users to manipulate items with a mouse as if they are moving objects around with their hands. In the process of moving objects around, users change the underlying data. The challenge for GUI designers is to imagine how a given TPF structure or command can be manipulated in a useful, easy, and visual way.

I’ve only touched on a few user interface elements of TPF/GI here. To read more about the TPF/GI user interface, please visit our web site at www.tpf-software.com.

Figure 3:  TPF/GI represents ECB's graphically in this window.