-----

User Interface

-----

At the moment, we are using the standard emacs-based interface for user input. However, we intend to replace it as soon as the rest of the implementation is stable.

What's wrong with the emacs interface?

Interfaces based on emacs are wonderful on vt100 terminals. The user has command-line editing and parenthesis balancing, can cut and past parts of forms, and can interact with scheme and edit files at the same time. These interfaces are a significant improvement on a raw tty window.

In an X-window environment, however, emacs interfaces have outlived their usefulness. One problem is that emacs is providing duplicative, less powerful, versions of services already provided elsewhere:

This helps make the emacs process far too large for the service it is providing, particularly when running a finished application.

Furthermore, the emacs interface to lisp seems primitive compared to newly built X interfaces for other programs:

A better solution

Our final system will have three components:

The user front-end watches the keyboard, the mouse, and any other input devices. It obtains the following types of input items:

It arranges the completed items in a linear order, which should be as close as possible to the order in which they were completed. X windows events from different devices sometimes appear out of order, so perfect temporal ordering is not possible. Non-form items are translated into scheme forms. Finally, the forms are shipped, in order, to the scheme interpreter.

The front-end will also store a history of the interpreter's behavior. This internal representation should follow the logical structure of the session, distinguishing user input, values of forms, and text printed on the standard output. A graphical display of this information should be presented to the user (the "history window").

The user front-end should support at least the following features.

For example, suppose that the entire interface fits into one window. At the top of this window might be a row of command buttons and, below them, a narrow sub-window for editing filenames for commands like load. Below that might be a large subwindow containing the history display. At the very bottom might be a sub-window for editing the next input form.

The user front-end program should be very small, so that it is not a burden when running final versions of applications on small machines. This means, in particular, it should be written in Xlib, not Motif or Tcl/Tk. It also means that the number of features (e.g. buttons) should be kept under control.

Editing of code files will be provided independently by the user's favorite text editor.

-----

Ownership, Maintenance and Disclaimers

Manual Top Page

Last modified