Project Athena - X Window System Users and Developers Conference, Day 1 [3/4]

[MUSIC PLAYING]

PALAY: My name is Andrew Palay I work at the Information Technology Center at Carnegie Mellon University. For those who don't know, the Information Technology Center is a joint project between Carnegie Mellon University and IBM. It also has some funding from the National Science Foundation.

This talk is going to cover the Andrew toolkit. I'd like to begin this talk by providing a short example of what the toolkit's all about. In particular, how I made this slide. And actually some of the other slides.

So I basically had the editor. In this case, I had typed in the text. And I selected a spot of the text and essentially asked to add a raster. This particular place, I added a raster. This object that we add into these will be referred to, and are referred to by the toolkit, as insets.

The inset comes up as its default size, given that I've added nothing to it. I then request to read a known raster from the file, And this point, in this case the ITC logo. If you note, the actual inset itself hasn't increased in size to accommodate the raster image. The user has control over that size, can actually make it larger or smaller.

Later in the talk, another slide you will see actually has a drawing. In this case, I selected areas that I wanted the drawing, actually created the drawing in place. In this case, I had the editing functions of the drawing editor.

And finally, in order to have this critique, I was able to send this document to various people asking them for comments. They are then able to take this file, edit the file, the objects themselves are fully editable when they arrive. And then send them back to me.

Basic concept behind the Andrew toolkit, first of all, is a toolkit for building user interface applications. As with all toolkits, it has to provide a set of basic components for building those applications. Components such as scrollbars, text, dialog boxes, the basic sort of components for laying out objects on the screen.

This toolkit, however, attempts to go further. It has this architecture for quality supporting cooperating components. In this case, as I said, the components are called insets. For example, we wanted to be able to build a system that allowed you to have a text document with embedded insets, such as tables, drawings, rasters.

Also, we wanted to be able to have a table editor, which provided the same functionality. So that I could place in text, drawings, rasters, et cetera, within a table. We also wanted the insets to be able to be used to provide-- to allow the user to build more complex insets. We wanted this functionality both for the programmer and for the end user.

In building a system in this way-- and I'll discuss the details a little bit later-- the line between what is an application and what is an inset blurs. The goal here is for people to build insets, which just happen to be able to run as applications. I can use a drawing inset as a drawing application. But others can use those insets to suit their needs.

Another key feature of this system is that we want it to be extensible. The basic facility for extending the toolkit is we allow for dynamic loading of code into running applications. So for example, in the Music department, a professor, or a programmer, could develop an inset that allowed you to edit musical scores. Or perhaps even to play musical scores.

Those insets could then be deposited within text files, just as I deposited the raster in the previous example. Just as easily as I included the raster image. It's done in a way that I do not have to change the running application for the text object. No additional work on my part, as the creator of the text object, would have to be done.

Another goal of the toolkit is Windows system independence. Our emphasis has basically been on X11. However, we believe we want to bring this functionality to other systems. Systems such as the Macintosh and OS/2.

Some of the current insets, or applications, however you want to look at it, that are available in the system-- the system comes with a multimedia editor, it's called EZ. We have a TypeScript facility which is similar to xterm, under X11. A fairly complete help system, the ability to preview ditroff output files, handle mail. A system monitor, called Console-- which I'll show a little bit about-- text, and a mode for editing C files.

The second group on this slide are a set of other objects, basically they're-- are part of the toolkit, but they for the most part, have to be labeled as sample objects. They're not as complete as the ones above. They are a demonstration of the functionality of the system, but they do require more work.

So here's a sample image of the screen. The window manager that's being shown here is a window manager written at the Asus development in Cambridge, it's called CWM, it will be made available with the X11, for X11.

The BE2 app, or excuse me, the Andrew toolkit applications-- it has an older name, it's disappearing-- run as any other X applications with whatever window manager you want. They can be run under an overlapping window manager.

Three applications being shown here are Console in the upper corner, the TypeScript, and the editor, EZ itself, in this case, editing a text file. Here's a larger view of the text component in the toolkit.

Text components, displays multiple fonts, indentation, different justification styles, it's optimized for display on the screen. The text is rewrapped automatically when the size of the window changes. It does automatic justification on the fly as you type characters. It also, however, provides-- as do most of the components in the system-- a way to print them on paper.

In this case, this is the C text object. For Emacs users, that's essentially equivalent to electric C mode. It's just specialization of the text object that understands about the C code, will rewrap lines when they get too long with proper indentation.

Comments are displayed in italics. Procedure headings are displayed in bold, making it much more easy for users to read and edit the text. Again the drawing editor. More or less in the flavor of MacDraw, not yet to the functionality of MacDraw, It has some other features that MacDraw doesn't have, but we'll leave those for another talk.

The system also comes with a table object, table inset. In this case, it's showing off the spreadsheet capability of that table. That table can then be embedded in text. I could have actually created a table within this text, in this case, a letter.

The user can then come in, and in this case, as can be seen, it selected the cell showing the gas expenses for one of the people. It is actually displaying the value of the cell in the message line, showing the user actually editing the spreadsheet in place.

Similarly, there's equations insets. In this case, we have equations within text. The equation inset understands about the mathematical structure of equations. You can cut out various pieces, paste them in, and they understand the relationship to other expressions within the equation.

The goal of BE2 is essentially to allow the user to combine these things in rather interesting fashions. In this case, I kind of was looking around, and decided what would be nice is to have a, more or less a electronic version of the CRC math reference guide. This case, an example of a table describing an Pascal's Triangle. Now this is really trying to describe it completely.

The text along the left side would probably describe-- have a prose description of Pascal's Triangle, but in this case, it more or less describes what the table is. It also contains an equation, set of equations describing the triangle.

The object over here is actually an animation inset. I can click in that area, I can tell it to animate, and it actually shows building Pascal's Triangle on the fly. And finally, in the lower right-hand corner, is a spreadsheet implementation of Pascal's Triangle.

The other thing with this slide is that we can basically arbitrarily nest insets within each other. So we have a table, which contains various insets, which in itself is contained within text.

As I said, the system comes with a Help system. The Help system allows you to get information on a variety of Unix programs and overview documentation of the system. As a matter of fact, it provides you complete access to all Unix man pages.

And, for the most part, has reduced the need, at least on the CMU campus, for producing printed hard copy help information. Users in this case, for example, can go over into the Programs area, click on an item-- in this case, I clicked on EZ-- and it brought up the help information for the editor.

The mail system we have on the CMU campus provides access to both mail and bulletin boards. And on the CMU campus, the number of bulletin boards, as can be seen in the very top of the screen, is about 1,450, all accessible via a single program.

Finally, in terms of showing some of the things that one can do with this system, this is a system monitor. This is actually about the worst one that has ever been created. Its design was show everything you could possibly monitor and different ways to monitor it. Basically, you have a clock, a CPU load-- actually, about four different CPU loads in different forms-- indications of paging activity, file system space, et cetera.

And finally, we have a style editor for the text. The text object actually has generic tags. You can change the definitions of those tags. The other thing to know with this style editor, is it's actually using various building block insets provided with this system. In this case, a set of buttons, and rulers, and rectangular layout packages for producing that inset.

So now the question is, how does all this fit together? Basic components in the system amount to two, which are data objects and views. Data objects are designed to maintain the information that you really want to display. For example, the text data object contains a string of characters, plus the style information, and where those styles are to be shown.

So, for example, for this slide, it contains the characters, plus for the words data object, that that should be bold. That information is the information that is saved in a file in the system. There are also a set of-- another set of objects, which are called views, whose responsibility is for displaying the information on the screen. They also provide the user interface mechanism and provide the mechanism for printing.

The advantages of doing this but are basically two. We get multiple views on a single data object, and we also allow the independent use of the data object to build other data objects to be used by applications developers.

And it turns out that, when I talk about an inset, I'm actually talking about a view data object pair. So let's look very briefly at the notion of multiple views on a single data object. This is very similar in flavor to the talk that was given right before this right, before the break. And one of the goals is essentially to share information, whether it's on one screen or on multiple screens, and whether on one server or multiple servers.

And in this case, I have a text object. The text object has two views pointing to it. One is a normal text view, which is what you saw before. The other one is a table of contents view. It only displays the headers, things that are headings, and subheadings, and so forth. They are each displayed in their own window on the screen.

When the user comes in say, for example, clicks at the heading in the text view, and types, changing that title, the corresponding change is made in the text data object, which then, since both of these two views are viewing that data object, is reflected immediately in both windows.

I can also go to the table of contents view, that window, change a heading in there, and it will be reflected automatically in the text view window. The split between data objects and views allows us to have two different views looking on the same data object. It allows us to have the same type of view looking at the same data object. In the case, for example, when I wanted to produce two windows on the same file. The equivalent of Control-X-2 in Emacs.

Or, even allowing us to have two views on the same data object within one window. A table of numbers being represented, not only as a spreadsheet, but also as a pie chart. And when I type in the table and change the numbers, the pie chart automatically changes.

Views themselves are organized in a tree structure. The tree structure is defined by their physical representation on the screen. Children are completely contained within their parent. However, siblings may overlap.

The handling of events and requests in the toolkit are you done using the tree structure. The interaction is almost entirely only between the parent and child. An event that will come down from a parent to a child, for example, include, update yourself, or here is a mouse event to handle.

Requests can be of the form, here are a set of key bindings that I want to have in place. I want to have the input focus. Or some of the requests that are made up the tree. By defining this very precise interface between parents and children, we allow for the easy inclusion of arbitrary objects inside of another object.

So for, example, the table inset, using that interface, can include any object, any other inset in the system. It is not a special case that it can only handle drawings, and rasters, and equations. Again, if somebody creates another type of inset, the text object is already set up to include it.

Extensibility in the system is based on an object system that we built. The toolkit is an object-oriented system. It's easy to extend, essentially by two factors. One is subclassing, given it is an object system, it is a single inheritance system.

So, for example, the C text object is actually a very simple extension to the text object. The only things that are really changed are reading and writing, so that it actually parses the C code to understand the various C constructs.

The object system also provides dynamic loading of the code. The system's similar to C++, it was designed looking at C++. We believe in the future, with some changes to the code that is generated by the C++ preprocessor, that we will be able to migrate to C++. And without losing any functionality in the system.

Final area in working that we had was Windows system independence. This is basically accomplished using two different types of objects. One is the interaction manager, it's the top most view of the view tree. Its responsibilities are essentially translating events that come from the Windows system into the Andrew toolkit event structure, and taking requests from its children, and posting them to the Windows system.

So, for example, when a request to have a cursor, that request gets up to the interaction manager, which actually posts the cursor to the X server. On the output side, there's a graphic layer. It's X11 based. It's-- can be easily extended. So, for example, if there is a definition for 3D graphics that's included in X, we can include it without any major difficulty within the graphics layer of the toolkit.

Finally, it's built on a notion of binary compatibility. That when you want to add in a new Windows system, the only code that actually has to change is the Windows system code itself. In fact, the way we run our system today, we run on two different Windows systems. And to support the two of them, we dynamically load in the appropriate Windows system code at runtime for the various systems.

Current status of the toolkit is, it's been in use on the CMU campus since August of this last year. It's been deployed on the ITC Window Manager, which, thanks to X, is going to be going away soon and relieving some of the headaches I have as User Interface Manager at the ITC.

And it actually has about 3,000 active users today on the CMU campus. The X11 version is in experimental use at CMU. The ITC itself is in the process of converting over to X11. The campus conversion is scheduled for June of this year.

IBM, as I said, who has funded the ITC, will make the Andrew toolkit available on the X11 release tape. In addition, there'll will be an early release, or early availability, of the toolkit, primarily for developers of the X11 system, to permit them to evaluate, integrate, and test the toolkit with their products.

These individuals will be able to retrieve the Andrew toolkit from MIT on February 3rd. I believe the actual site where it can be retrieved from will be posted on the expert bulletin board. This is an early release of the system.

Currently, it has only been fully integrated with the IBM software. And although, can be picked up by all users, it's not intended for end users. End users should really wait till the full release of the X11 tape.

During that, prior to February 3rd, in order to try to integrate the system with the various X11 systems, we invite developers of X11 systems, and potential developers of toolkit objects, to the ITC, to understand more about our software and to evaluate it for their use.

IBM and CMU will continue to support the Andrew toolkit and to make it available. We expect to continue to perform development of the toolkit, including adding objects-- and I'll actually list a couple there-- and to take into account feedback from users.

We have a strong desire, and one of the reasons for putting this out on the X11 tape is, we have a strong desire to work with others. Both this community, in terms of deciding where the toolkit has to be extended, and also with other commercial vendors.

We have been talking with the IBM Austin developers, the developers of AIX. They are strongly interested in using the Andrew toolkit for their X11 toolkit, in their AIX2.2 release. We've also had discussions with Sun to integrate our toolkit with their software.

The list of objects I gave before will be what will be included with the X11 tape. Some of the other objects that we have-- that we're starting to work on, one is a graphical shell for our user community, at least on the CMU campus, and for a large number of people, the C shell is not a very easy thing for them to learn.

There's a Modula-2 text inset, similar to C text. A graph, in terms of network editor. And also, we plan to improve the release components. We are, of course, open to suggestions of other things people think that we might want to work-- what we might want to work on.

There is a birds of a feather session for discussing the Andrew toolkit tomorrow morning. At that time, we will actually present a demo of the system. We will also have available, at that time, or we hope to have available, a list of some of the sample interfaces in the toolkit.

Also, out on the tables in front, there are large numbers of copies of the USENIX Paper. It will be presented at the upcoming USENIX conference in Dallas. There are more than enough as far as I understand for all the people in this room. If you haven't picked up one, you should.

The Andrew toolkit utilizes this same paradigm, based on an architecture that makes it easy for programmers, and users, to combine insets to form more complex insets. Further, these insets can be saved in files, and mailed to others, where they can be modified at a later time. Thank you very much. Any questions?

[APPLAUSE]

AUDIENCE: What hardware and software is needed to run the current version of Andrew?

PALAY: The current version-- is this on? Yeah. The current version, under X11, well, the current version at CMU you runs on Sun's IBM RTs and MicroVAXes. Okay, so the basic portion of the toolkit, outside of the X11 code, has actually been tested on all three of those machines. The X11 version itself has, for the most part, only been tested right now on the RT. That's one of the reasons for the early release, is to get it integrated with the other systems, prior to the next X11 release.

We've actually run it on Suns, with some minor bugs, given we have an old version of the Sun server. And we are in the process of getting it, of bringing up the VAX version. Okay, we are interested in other versions that will be available. Those happen to be the three machines that currently exist on the CMU campus today in large numbers.

AUDIENCE: Okay, and those servers, are you using a standard version of the OS, or using some local derivative?

PALAY: Standard X11. Standard X11, standard operating system, sorry.

AUDIENCE: Thank you.

AUDIENCE: I wanted to know, how much of X-- how easy it was to adapt to X11, and if there are any features of X11 that you would like to have seen, that weren't there? Or, basically, any mismatch between what you want and what X11 provided?

PALAY: We generally-- the major part of X11 that we end up not using is, we do not use a large number of X11 windows. Our original intent had been to produce for each inset, a window behind it. It turned out that that did not provide us-- given our model, where we have this strict hierarchy, in terms of parent and child control-- did not provide us enough functionality.

As it turned out, we actually made a proposal to modify it. And that wasn't actually necessary to do, since we weren't gaining enough by using separate windows for each inset. X11 has served, outside of the fact that it's been in transition continually, or at the same time we've been developing the toolkit, has served as a very good vehicle for our software.

AUDIENCE: I was wondering if the toolkit that you've built is built on the toolkit Intrinsics that we heard about yesterday? If you've built it on their XLive and why.

PALAY: The toolkit is not built on the X11 toolkit Instrinsics. The basic structure of the toolkit and the X11 Instrinsics don't match very well. One of the separations that essentially has to be made in this structure, to allow two objects to more or less share the same real estate, is that the parent ends up having to be in control of what events go down to the child.

It turns out under X11, there are certain events that are trapped by an overlapping window, that never get to the window that's underneath. An exposure event, for example.

If the top most object does not want to have the expo-- is not interested exposure events, they're not moved down. Those things prevented us from using the Intrinsics, also along with the problem of that the X11 toolkit has been more of a transition than X11 has.

X11 has been very stable, especially if you compare it against the X11 toolkit. And, so using that as a base, we couldn't do it. The other problem with using the Intrinsics is that we're very interested in Windows system independence.

X11 is an important player in this arena but, especially within a university community, where students have machines away from campus that are unattached to a network, and they would like to spend the least amount of money that they can supporting similar applications on lower power hardware, is important to us. And if we built it upon the X11 toolkit, that would not have been possible.

AUDIENCE: But you could build your toolkit on the Intrinsics, that's what I was asking. Not based on the toolkit-- any particular toolkit.

PALAY: The Intrinsics are too closely tied to the X11, to X11 itself.

AUDIENCE: Okay.

AUDIENCE: I'm interested in the cost, both in terms of time and space in creating insets. It looked, for example, in looking at your spreadsheet example, that the text labels didn't share the same attributes of font size, and so on, as the surrounding text. Do you in fact use text insets to create those text labels? And if not, [INAUDIBLE]

PALAY: You can-- the spreadsheet provides both facilities. Okay, provide both those facilities, basically because it serves both the role as a spreadsheet and as a table mechanism. Okay, people are very used to just dealing with text in a very simple fashion.

And they do not need the full power of the text object, when they're believing that what they are using is a spreadsheet. When they want to, for example, in the case of Pascal's Triangle, that was multi-font text, and it was very easy for me to put that in.

And the cost is no worse-- actually, it's the same, and actually reasonably good, whether or not I use a text inset in that case, or the text object, or text component of the spreadsheet.

AUDIENCE: Do you have an experience in actually using, say, very large spreadsheets, say, thousands of cells and replicating [INAUDIBLE]

PALAY: As I said, the spreadsheet, the bottom list, which included a table slash spreadsheet object, are sample components. They're not to the point of-- I could not do things I could do with Microsoft Excel, for example, in that spreadsheet. Okay, that takes a much larger amount of work. And one of the reasons for wanting to get this out, and actually into the hands of vendors, is hopefully if it becomes accepted, people will start developing those types of applications.

AUDIENCE: Does CMU have plans to begin migration of this toolkit to C++?

PALAY: We've been discussing that, especially with people at Sun, recently. Basically, the major problem behind using C++ ended up to be that the code it generated did not allow dynamic linking of code. And, in order for us to support that under C++ and make it widely available, it would have required people to have source licenses to C++, because we had to modify the preprocessor.

In our discussions with people at Sun, along this lines, they believe it is important to provide that. We believe it's important provide it. When that occurs, I would rather not have to support our own object system, when there is one suitable for the task. Thank you very much.

[APPLAUSE]

GAJEWSKA: Hi, my name is Hania Gayewska. And I work for Digital's Western Software Laboratory in Palo Alto. I won't give a talk, I will show you a videotape. From the earliest days of the design of the XTK toolkit for X11, we had a vision for how user interfaces would be put together.

This vision did not involve programming, but rather putting together user interfaces interactively, using some sort of an interactive editor. Unfortunately, we are a very small group in Palo Alto. We did not really have the manpower to assign somebody to write such a user interface editor. So we did what one normally does in such situations, we hired a summer student.

And what you will be seeing here is her work. I was hoping that she would, in fact, show you her system on this videotape-- that's part of the reason for having a videotape, rather than a talk-- but summer students are hard to track down once the summer, is over. So you will actually see me doing it. It's not my work, but I do my best to show it to you.

If you if you are very far back, you probably won't get much out of it, because image is rather small, so. Hi, I'm Hania Gajewska, and I will show you today a user interface editor written by Ann Mei Chang.

Ann is a undergraduate at Stanford, and she spent the summer of '87 as a summer intern at Digitals Western Software Laboratory, which is where I work, as well. Ann's work was inspired by the work of Luca Cardelli, of Digital Systems Research Center.

This talk will not assume any particular knowledge of X or X toolkit. And, in fact, in order to use the interface editor, you need to know very little about the toolkit. However, in order to understand and talk a little better, it helps if you know some very rudimentary toolkit concepts, such as, if you know what a widget is and what a widget resource is.

The purpose of the toolkit, and in particular, of the user interface editor, is to help separate the creation of user interfaces from the programming of an application, of the functionality of an application. For example, those of you familiar with Unix may be familiar with Unix mail systems MH, MHE, and XMH. All these three systems use the same underlying functionality called the same functions, but present very different user interfaces.

Our user interface editor allows you to create a user interface in a what you see is what you get, or WYSIWYG, way, by direct manipulation of widgets on the screen. And you can do that independently of programming the underlying functionality. You can program the functionality first, and then create an interface, or vice versa. The two are completely independent actions.

Once you've programmed the functionality, the running application would then read a description of the user interface that you've created using our editor dynamically as it runs. So it is not necessary to recompile, or relink, your application in order to change the underlying user interface.

Our system can be contrasted that with the old style user interface management systems, which allowed you to specify user interfaces, again, independently of functionality, but you would specify them using either some sort of a declarative language or a set of commands. And that specification would then be compiled and linked together with your program. So in order to change a user interface, you'd have to recompile a new description of it and then relink your program.

The advantage of a user interface editor, over a user interface management system-- and the disadvantages, in fact-- are similar to the advantages and disadvantages of a WYSIWYG text editor, such as MacWrite, as compared with a text formatter, such as TeX or troff.

With a WYSIWYG text formatter, you are able to get things more or less right the first time, but you sacrifice an overall-- an enforcement of overall uniformity. With a text formatter, or such as troff, you can enforce uniformity, say, by a set of macros. But it may take you a few times before you get things quite the way you want to-- you want them, because you don't see what your commands will result in until after you process them.

This system, our user interface editor system, is based on a old version of the X toolkit and an old X11 server. So some of the interfaces that you will see in the programs that I will show you are in fact out of date. This is not particularly important here, because the system was intended merely as a prototype and an existence proof. And we feel that it succeeded as such an existence proof.

So now let's see the user interface editor in action. The Large window in the center of the screen is the user interface editor running. It consists of several areas which have different functions. So I'll now go through these and explain what they are.

At the top of the screen, there is a message area, which displays messages from the user interface editor to the user, such as a welcome message at startup. Below that there is a button box, which contains buttons that allow the user to operate the user interface editor.

To the right of that is a box which displays the dimensions and coordinates of the a currently selected widget to assist with placement. Way on the left here is a palette of the available widgets to build the interface with. Now this set of widgets was built in when the user interface editor was put together, but it's extendable. There is no reason why you couldn't add more widgets or use different widgets.

The area to-- the large area in the middle, here, is the work area. And that is where you put the widgets together to build your user interface. So I will now build a user interface. I'll select the form widget here and drag it over, resize it.

You'll notice that in the upper right-hand corner of the window, the coordinates of this widget and size are now displayed. I will now select a label. And drag it over and place it inside the widget. And a command button.

Now I have my interface more or less laid out, but I'd like to edit the resources of these widgets. For example, to display different strings in them. So I will choose Widget Options to edit the resources of the label widget. That pops up a dialog box, which lists the resources of the label widget.

Now, when I edit these resources, I am in fact interacting with little resource editors, that each of the resources has an associated resource editor. So when I add widgets to the user interface editor, as long as the resource types of the widgets are standard resource types, the Widget Option dialog box will display the correct set of resources.

If I want to add a new resource, I need to write a resource editor for the new resource type. There is a widget named Resource here, which is used to, for instance, set defaults for the particular widget in your DOTX defaults file. There is a widget label which I will modify.

There is a justification of this label, such as left, center, or right. I have border width, the border color, foreground and background colors, default font name to be displayed. So when I am happy with the values of these resources, I press OK, which cancels the dialog box and displays the modified widget here. And it looks like I need to make my form a little larger.

And now, let's edit the resources of this Command button. I'll select Widget Options again. Now the resources of the Command button are in fact very similar to the resources of the label. I will change the command to say-- label to say Quit. Left justify it again. The only difference is this callback function resource here, which allows me to specify a string, which will be used by the program that reads in this interface to bind to a function.

So again I press Quit. Then instead of Command, I display Quit. Now I can select Save from the command buttons here to save this dialog. And then I will save it file, test.dat.

Now I will open a terminal emulator window to show you what the file that I just saved looked like. It's not very interesting, it just has descriptions of the widgets. What's more interesting is the program that reads in this user interface. So I'll show you that next.

It starts out with some declarations. And then it defines this function, Quit, which just sets this global variable done to one. It's written in Modula-2, by the way. There follows some toolkit and X initialization routines. And then this call to get data, which actually reads in the all file written out by the user interface editor.

Then this line, add binding, binds the string quit, which we've specified when we wrote out the user interface description to the function Quit that we've defined in this file. This-- then we create the various widgets, create the top level widget here. This is old style toolkit interface.

And finally, start by setting done to 0, and executing this loop which tests the value of done, while it looks for events and dispatches events. Now when the Quit button gets pressed, the function Quit gets invoked, then gets set to 1. This loop exits, and the program terminates.

So now suppose that-- now suppose that I want to translate my user interface to Italian. So I'm going to go back to my user interface editor. And I'm going to-- I want to internationalize, so I'm going to translate this label to Italian. I select Widget Options. And oops.

There I go, now it's in Italian. And I press OK. And I will save this interface in the same file, test.dat. Now, when I invoke the same program test, I'm not recompiling it here. In fact, presto, it pops up the same user interface with the label now in Italian.

So now I'm going to go back to the user interface editor and show you a somewhat more complicated user interface that I've stored. It consists of a label at the top, two command buttons labeled Plus and Minus, and the Quit button, and a text string here. This is a Boolean, and just ignore it.

So let's look at the Minus, the options of the Minus command button. The only interesting thing here is that there is a callback function bound to Minus, the string minus.

And if we look at this text string area here, and look at its options, we see that it has, rather than a callback resource, it has the source string resource. You can bind where the characters that get displayed in this text area come from. And you do this binding using, in this case, the string test string.

So now I will show you the program that uses this interface. It starts out just as the last one, with some declarations. Then it has the now familiar Quit function. The Plus function here increments a global variable and displays it using this pointer, character pointer test string.

The Minus function decrements the global variable. And here is the main body of the program, which is very similar to the other one. It, again, does some initialization. It allocates some space for the string that's bound to the text string area, this pointer test ring. And then binds, again, binds Quit to the function quit.

It binds the test string to the character pointer test string. And then Plus, binds Plus to the function Plus and Minus to the function Minus. And the rest of it looks the same as the other program.

So now if I invokes this, the program that uses this interface, I, in fact, have a little counter that I can increment, and decrement, and the Quit button still works.

Finally, I'd like to show you an interface that may be familiar to some of you. And to do that, I'm going to copy the description of it to the file which the test program, which we've looked at, uses to get the user interface description from.

Then I'm going to run test. Now this will take a little while to start up, because it's a large file that contains many widgets. And the old toolkit took awhile creating widgets. The new toolkit is much faster at it. But the important thing is that, again, we're running the same program test. We haven't recompiled anything. But the user interface we have read in is far more complicated.

This is, in fact, the user interface for the XMH mail editor. These are the various XMH command buttons. And none of them are bound to any functions, except for the Close button, which is bound to function quit. So when I press the Close button, the program exits.

[APPLAUSE]

I can do my best to try and answer some questions here, if there are any.

AUDIENCE: It seems, from what you've shown, you could also produce the boilerplate C code, for the widget themselves. And then just have places where you put in the functions that you need. At the moment, you spend a day writing just the boilerplate widget code. Is there any plans to do something along those lines?

GAJEWSKA: It would seem to me that this supersedes, if you will, doing that. I'm not quite sure I understand your question exactly. You mean to subclass widgets or to use widgets?

AUDIENCE: No, that the test program. Inside, it bunch of bindings of resources to values. It seems to me that that program itself can be generated trivially from what you've done.

GAJEWSKA: Actually, the main program was written by me, and but the only part that was written by me was what I've shown you. I haven't written any other code. The main program with the new toolkit, it looks a little bit simpler in fact, because the main loop isn't there. I believe it's hidden away. The bindings need to remain there because different user interfaces-- different user interfaces might specify different strings that that will actually bind the activation of a button to a function.

So those add binding outlines need to stay there, but that's pretty much the only thing that needs to be there. And that's pretty much the only thing that was there. So, once the main loop goes away.

AUDIENCE: Okay, thanks.

AUDIENCE: I'm interested in what the future of the user interface editor is? What are you doing with it now?

GAJEWSKA: This was built in our-- out in the West Coast, using the old toolkit. And we view it as a prototype. And the hope is that eventually, it will result in a product. And I don't really know what is going on in that respect. But I assume that will happen.

AUDIENCE: What kind of display hardware were you using to make that video?

GAJEWKSA: What type of which?

AUDIENCE: Display screen.

GAJEWKSA: Gee.

AUDIENCE: What are you running on there?

GAJEWKSA: It was an MicroVAX whatever, 26-something. What's the-- Does anybody know the display?

AUDIENCE: 256.

AUDIENCE: VAXStation 2000.

GAJEWKSA: There you go.

AUDIENCE: Thank you.

AUDIENCE: I've heard several references to old toolkit, new toolkit. Can you explain what you mean on your terms, in reference to the toolkit that was on the September release of X11?

GAJEWKSA: September release. In toolkit terms, four months is centuries. So I have a hard time remembering, but I believe-- I believe that this is pre-September.

AUDIENCE: Where does someone get the latest and greatest toolkit?

GAJEWKSA: The toolkit is available on the MIT tape. The latest and greatest this is what's on the MIT tape. Each subsequent MIT tape has the latest and greatest toolkit.

[LAUGHTER]

[APPLAUSE]

I think that may be a little unfair. The time frame in which this was all happening was very short. That is, while Ann was writing this, the toolkit was changing underneath her. More than that the server and XLive interfaces were changing underneath her. And when you have a set of dependent components, you can't, it's impossible to get it right the first time. And so that's probably the reason why there have been changes along the way. I think things are going to start stabilizing, or they already have.

AUDIENCE: One thing I would like to point out. We work at some very similar effort that lets you create interactive interface. It also lets you interactively create functions to it. It's very important work, I feel, and I would like to talk to you about it after.

GAJEWKSA: Okay, thank you very much.

[APPLAUSE]

HOYT: Good morning, my name is Kurt Hoyt. And I'm currently with the Software Engineering Institute, which is a federally funded research and development center contracted to Carnegie Mellon University by the Department of Defense. The project that I'm working on at the Software Engineering institute, it's called Serpent. And what we're hoping it results in is, essentially, a rapid prototyping system that's based on the X toolkit.

Now we actually have a customer within the Department of Defense for what we're producing. So what we're doing right now tends to be a little bit targeted towards the needs of our particular customer within the Department of Defense. However, the SEI does have its own agenda. And is hoping that-- the SEI management and our goal in the project-- that it's general enough that it could be released to just about anyone who wanted to make use of it.

What I'll be going into is a little bit as an overview and background of what Serpent is and what we expect it to do. Then I'll give a short little example of how to build a simple Hello World program using Serpent. And then I'll go a little bit deeper into a couple of the components of the system itself. And then tell you where things are at, in case you're real interested in having a copy of it some day.

Just as a sidelight, what I'm going to be talking about is work in progress. So hopefully things will stay like this, but there's always the chance that they'll change a little bit. This is the basic idea of Serpent, and how we expect people to use it.

There's two different people, aside from your basic application writer, that get involved in building these user interface. The person up at the top-- I I know I've got a zapper here-- is our dialog specifier. Now this may not be a programmer, or software engineer, or whatever you want to call them today.

This might be a user interface specialist of some sort. To where they would actually sit down and use an application for Serpent, which we call our dialog editor, which is much similar to what you just saw with a few more features added.

And the dialog editor would then generate a dialog for the user interface. So you wouldn't be specifying just the pieces, or the widgets, or whatever else you'd want to use, you'd also be specifying how those would interact with the user, once they were actually on the screen. That dialog within be stored away in some sort of compiled format.

And then later on, your end user, when they sat down in front of the terminal, what would be in front of them would be these layers. There's the X toolkit, which is what's closest to the user. That, through X, is what actually physically speaks to the user. Underneath that would be the Serpent runtime system and the dialog running the user interface.