Project Athena - X Window System Users and Developers Conference, Day 1 [3/4]
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?
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: 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.
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.
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.
AUDIENCE: What are you running on there?
GAJEWKSA: It was an MicroVAX whatever, 26-something. What's the-- Does anybody know the display?
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.
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.
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.
This would all communicate with the application, which was actually written to activate the prototype. The prototypes that we want to write with this system are active prototypes. It's not just storyboarding, we want to actually have prototypes that move, and dance, and all of the kind of good stuff.
That way, when these are sat down in front of the generals that these user interfaces are being built for, they can then fiddle with them and say, well, gee, I want to see what happens when such and such happens. You can then change them, and they'll move, and things like that. It's kind of hard, when you're building a large system, to try to figure out what your user interface is if your prototype doesn't move.
We decided to build our prototyping system on top of a user interface management system architecture. It uses the same old standard UIMS architecture that's been preached at various user interface conferences for the last year or so.
And we're also going to build on lots of existing software. We decided that we didn't want to reinvent a lot of wheels. And so we picked up X11, and the X toolkit, and also OPS83 as the engine for our dialog manager.
And then, to communicate between the application program and all of this other stuff that we're going to write, we've picked a database-style interface. These might all be different processes that are running back and forth.
And we didn't want to spend a lot of time trying to send complex data structures, which may be written in various languages, who have various levels of complexity in the data structures they can express over this interface. So if we used all of the C data structures in our interface, and someone wanted to write a Fortran program, they might have trouble communicating.
And then we use, inside the dialog manager, a structured production model to specify the dialogs. And of course, the editor that we build would generate most of this, so that people aren't writing a lot of OPS83 code.
The basic decomposition of our system goes like this. You have your application, which is what runs the prototype. Now it can be to whatever level of completeness you want the application to be that runs the prototype. It can be something that's just mocked up and reads some dummy data, or it can actually be fairly close to the real system you would act-- you would deploy later on.
And then Serpent consists of everything else. And the basic parts of Serpent are dialog manager, which again, uses OPS83. Serpent X, which is the particular portion of the program that I'm responsible for, which is going to be based off of the X toolkit, plus some additions, which I'm going to describe later. And then we have the presentation portion, which is, of course, the next layer down, which talks directly to X Windows.
How the data flows in this system would be, you'd have your application running-- and I didn't show the user in this. I probably should have, because it goes both ways. But the application has its own local data that it wants to worry about. And of course, the idea with the UIMS is you want to break out the user interface from the application programs.
So that the application programmer isn't spending all their time worrying about how the user interface is going to work. It can just worry about chunking its numbers and manipulating its records. The idea being that once it gets those records, it throws them at Serpent and says, here, display this. And I don't really care how. And so we have our shared data in between the dialog manager and the application, so that they can communicate back and forth.
The application would throw records into the shared data, the dialog manager would read records out, maybe put some more records in, depending on what's going on. The dialog manager has its own local data to keep track of the dialog and what's going on. And then, once the dialog manager has figured out how to display a record, it has to translate that into stuff that Serpent X and the X toolkit and X Windows understands.
It puts it into a different part of shared data, using the same interface, and then Serpent X would read that out and make the right calls to the toolkit or to X. And then, of course, it works in reverse, with the events that the user generates then go straight-- go back through, and can either go just into the dialog manager and back out, or all the way back to the application, depending on how things are running.
And again, our communication mechanism that's in between all these different pieces-- in fact, I'll put the picture back up, so you can see it-- is this shared data. And it's kind of the weak link in the chain, because it's not very expressive, as far as the data that you can put in-- that you can describe, using our shared data system. It uses a database model, so we gave you, essentially, the basic types that a database will let you have, which is essentially a table of records.
We feel that the database model is well understood by lots of application programmers, so that way, they're not having to get into any of the details of X, or how to build user interfaces, and things like this. And now we have the records that we've put in here are active.
And what that means is that the records know when they've been modified. And when a record has been modified, it then lets all the folks that are interested in that record know that the record was modified. So you've got active data in the system. And each of the records that we put in the shared data were referenced by a specific and unique ID value, so that you can query the shared data, say, well, give me back what you've got on this record.
This does create some work for the application programmers, that it has to manage a mapping between, say, records it keeps locally and wants to share with X, between those records and the IDs of the data that it put into the shared data interface. And again, this shared data is used to communicate between all the different components of our system.
Now I'd give you a quick idea of how this would all go, once we develop something. One of the things you're going to have to define, again, is your interfaces between all components. So here would be a sample shared data definition for our Hello World program.
All's it is is essentially, it's a variable length string. One of the trouble we run into lately, in designing all of this, is how you pass strings across this interface, because different languages like different flavors of strings. Certain languages, you can only have fixed-length strings and that's all it sends. C has null-terminated strings, Ada uses variable-length arrays to represent strings.
And so if you just pass the straight string from each of the different languages, you're going to get confused. At least the interface is going to get confused. And now, you may not be able to get the data back. So what we did is we invented something called the buffer, which is essentially a two-element record containing a length and a pointer to the data.
So this mimics a variable-length string inside this text record. Now what comes with Serpent, this user that's going to do this, he already has all of this stuff. And since the same interface for shared data is used between Serpent X, there's also one of these sorts of things defined for X, as well.
So all the widget definitions have been turned into record definitions that look like this, which means that, for the dialog manager, all the classing and subclassing views of widget data tend to go away, with the data still accessible. We just tend to coalesce all that stuff into one big record, instead of a collection of three, four, or five little records.
So once you've got this shared data definition together, you need to somehow define the dialog to translate-- to translate this shared data definition of your string into a widget that she might throw up on the screen.
And I picked the label widget, since it's the simplest to use for this sort of thing. And so this might be the definition of a label widget. It's somewhat obscured, because I didn't want to go into all the details of what a label widget was.
But here's all the fields. And if you know lots about the toolkit, you can see that some of the core widget attributes have been put together with some of the label widget attributes. And that's just one of the things we had due to the lack of expressiveness in our shared data definition.
But the job of the dialog writer is going to be to take this text record and put it inside one of these label widgets. Now if you've noticed, there's not a lot here, that's in here. Which means that both the dialog manager, and particularly, Serpent X has to provide meaningful defaults for lots of these values.
So either your dialog writer, like here, is going to set the x and y values, say, of where this widget would go, and all these other sorts of things. Or Serpent X has to have reasonable value sitting down inside of it.
We wanted to be real minimalist in the amount of data we passed back and forth across these interfaces, because we're going to be doing inter-process communication. And we don't want to send lots of data, so we've reduced the amount of data you send across. So in this case, of course, this is going to be quite different, we're hoping, well, we're actually going to develop a WYSIWYG sort of user interface editor to go with this thing.
But just for the discussion, this would be your label widget, and here's the WYSIWYG part right here. And this just tells you that this label in brackets, is there's a string going to go there, I just don't know what it is right now; . And here's some information on it. And once this dialog was all put together and compiled, and I've left out a few things, so far as defining the logic of the dialog.
You then need to write the application that would generate the picture on the screen. And here would be the application code itself. The shared data interface has a processor with it that takes those shared data definitions and turns them into something more meaningful for the language you want to write in. We want to write applications in whatever language the application writer likes to write applications in.
For the Department of Defense, they tend to be partial to Ada right now. And so that's one of the keys, is we have to be able to write Ada programs that interface with all of this stuff. So it would turn that shared data definition into Ada code. In this case, it would be turned into C code, we just include it.
And then I do all the things that I need to do to initialize the system. Since we're using a database model, all data that goes across the interface is enclosed in transactions, just like you'd get on the databases you'd buy off the shelf.
So I just sent the data in the message. The text record that I wanted to find. And then I just send that text record-- there's the type name of it-- into the interface, and once I've done that in the application, I'm done. And I'm bugging the guy who's writing the interface. I would like some sort of wait on data from the shared interface to get data back. He didn't put that in his original design.
Everything is all polling, and I'd like a blocking call. So I'm arguing with him over that. So I put a little infinite loop down here, so the program wouldn't terminate and everything would vanish instantly.
So that would be all it would do. And then, wah-lah, you'd compile and run the program. And a little box would show up on the screen that said Hello, World. And so hopefully, we haven't added too much complexity to the system.
So again, just to give you a quick review of that. The shared data that I created, the application would run, put the data into this interface, the dialog manager would do the translation into the X shared data. Serpent X would read this out and actually display it on the screen. So there's lots of things that go on. Now to get a little bit lower level, is that the Serpent X component, again, is built on top of X11 in the X toolkit.
Since this is a moving baseline, and the stuff on the other end, our interface, and our dialog manager is a moving baseline, that's what I've been working with lately. Is programming, or designing, the two moving baselines, which is kind of fun. I had to do one, before I came to SEI, but I guess since that it's at a university, you should be able to work to two moving baselines and more on it.
What I'm doing, is all's that I'm doing, is I'm translating those shared data records into widgets. So that means I've got to then create widgets, I've got to keep track of these widgets. You also have to remember that these widgets have to be able to be referenced by someone else coming in from shared data.
Like, if the dialog manager decides it doesn't want to keep all the data around, and it wants to know what all the values from the label widget it just created were, it needs to be able to give me that ID value. And I need to turn that ID value into widget values and then send it all back. So there's a lot of translation that has to go on.
Not only that, I needed to enhance the toolkit a little bit. I needed a couple of widgets that weren't provided in the sample widget set. I also needed to do some ad hoc graphics on the screen, since the displays that the people want to generate don't consist of all rectangles.
I needed to do things like lines, and circles, and be able to group them together, things like that. And then we needed a different sort of event mechanism, some higher level events than what are provided by X the toolkit.
So just to bang on the toolkit a little bit, it provides a the good beginnings for building user interfaces, but everything that I would want isn't there. And I guess that's the way it's supposed to be, so it doesn't really bother me all that much. But right now, some of the things that it doesn't support, that I'd like to have, are things like pixmaps, button and label contents.
Right now, your buttons and labels, the way they distribute them, can only have strings. Well, I wanted to have iconic buttons and they're not provided there. So I went and did the work to subclass those widgets and generate picture buttons instead of text buttons.
And not only that, there's no pickable graphics support. There's no way to do ad hoc graphics into a widget window and be able to have those graphic primitives act like widgets themselves, so that I can select them, and move them around, and do a MacDraw-type interface for graphics.
So once again, to complain about our shared data, that it's very elementary. You get integers, reals, fixed-length strings, variable-length strings, and records. And you can't have records of records. That was something I was rather upset about, but it got too complex to do records of records. But we do have a semi-pointer mechanism. ID values can be assigned to record components, so you can sort of mimic pointers if you'd like to.
Again, these shared data records are referenced by a unique ID value generated by the interface itself. So when you say, I'm going to add a record, the interface sends you back an ID value. And half of the interface is linked into your code, so you're not actually going across a IPC call to get an ID value, those are generated differently.
And again, you can use the IDs as pointers. And we can also send partial records across this interface, so that makes for some interesting times, as far as making sure you get good default values. And then I've got to convert all this stuff to X11 and X toolkit structures. And then go to all the mapping, from IDs to X11 objects, and back again.
The new widgets I needed, again, picture buttons, because I want to pixmaps for label contents. And the other one is- I call it a canvas widget. The idea is I want to do ad hoc. I do lines, I want to do circles, I want to do rectangles that aren't windows, I want to do all that kind of good stuff.
Not only did I want to be able to pick the individual graphic primitives that I create, and I also want to group them together in GKS-like segments. Maybe even hierarchies of segments, and all this other kind of good stuff. So that we can draw good user interfaces. And not only that, it'll up supporting MacDrae-like applications fairly well. So those are the two new widgets I expect to come out of the project.
The other nifty thing that Serpent X has to do is higher level events. The guys designing the dialog manager said, look, you can't be sending ButtonDown events across this inter-process communication call all the time. I want something a little bit higher level. And I said, okay, fine. Why don't we get a system so that if you can define something, in terms of lower-level primitives, why don't you just give me that definition? And instead of sending you back ButtonDown, MouseMotion, ButtonUp, I'll send you back Drag.
And so we came up with this scheme for using regular expressions, which can be downloaded from the dialog manager to Serpent X. And Serpent X will keep track of all of these regular expressions. You can tag one on to every single widget, or every single object, that's created from the dialog manager down to Serpent X, and you can change them dynamically at runtime.
So that if, for some odd reason, you want Drag to be ButtonDown, MouseMotion, ButtonUp, at one time, and then five minutes later, you'd rather it be ButtonDown and MouseMotion, with no worrying about ButtonUp, or whatever, you want to push the A key, instead. Whatever, you can do that later on. Or you can do it actually on the fly, within the same program.
Now none of this system is going to work without this dialog manager in between, to provide the mapping between the application data and the X data. We're kind of hoping that we can put together, in some form, a downsized dialog manager that's more directly connected to Serpent X. So that it might be more generally useful, without having to have all the full up-- because this project's a lot bigger than I've described.
I've given you maybe 50%, 60% of what were the end results should be. But some of it, or the other stuff, is probably not of much interest to the X community, so I've left it out. But we want to be able to get a smaller dialog manager together. And if we can't write it, maybe someone here is interested in doing something like this, that would allow you to do all these translations.
It controls the functionality of the interface, what happens when I do a drag, what happens when I do all these other operations? And it also allows for the classing and subclassing of its own internal data. So you can kind of generate new widgets inside the dialog manager, so long as you can translate them into the shared data records that are on the other side.
And the widgets that we're going to create for Serpent X will seem like they're intrinsic to the dialog manager. So the dialog writer, it doesn't have to be greatly interested in what shared data records look like. We're hoping to hide a lot of that from them.
Where are we at? Well, the component interface, the shared data stuff is being coded right now. At least, the code that runs the interface. The code that runs the processor is still being worked on and it's in detail design, down here. Serpent X, the stuff I'm working on, I'm coding because I'm tired of designing to two moving baselines. So I said, forget it, I'm going to just start coding.
That, I found out, tends to work easier sometimes in the long run. Is I just start doing the work, then I can worry about fixing things with the moving baseline later on, instead of trying to explain, in documentation, two moving baselines. The dialog manager is still in a detail design, that's a big piece. But we're still expecting to get this done by this summer.
Now we wanted to be able to make it publicly available to everybody and anybody we can. The only trouble is, is we found out that the OPS83 engine that we have isn't publicly releasable. It's a commercial product, which means you have to go out and buy an OPS83 engine, in order to run our system.
And that was the reasoning, we want to go behind, perhaps, creating something scaled down that shortens the distance between the application and Serpent X, so that we don't have to have the OPS83 stuff included, but still publicly release everything else.
So if you think this is a good idea, but are interested in what it runs on right now, this is it. The SEI tends to have lots of MicroVAX II/GPXs running around, so that's what we tend to use. We're going to run under Ultrix 2, the X Windows system version 11, the X toolkit and the OPS83, again, for the full up system available commercially.
So that's it, in a nutshell. Serpent, which is our hope-- well, which is a the rapid prototyping system, which, it will be useful to folks besides our customer within Department of Defense. I told you about a little Hello World program, a little bit about the internals of Serpent X, and the dialog manager, and gave you a bit of status on the program.