scheinin@uiuc.edu (Alan L. Scheinine) (04/19/91)
Apollo-like display manager and editor. --------------------------------------- Two aspects of standardization, that are sometimes mistakenly lumped together, are the "machine interface" and "user interface." (Permit me to mint in this essay a few new usages for terms. I welcome others to suggest better ways of expressing the concepts.) Specific examples will sometimes straddle the distinction I wish to make, nonetheless, to explain by example: operating system commands, program callable primitive functions, and a graphics language such as PHIGS can be considered the machine interface. The look and feel of an application is a user interface. I want my programs and my knowledge of system administration to be portable -- which is what I expect from a _standardized_ machine interface. I do not mean to dismiss the value of a standardized user interface, such as Motif. However, _unique_ standardization at the user interface level is not desirable. In particular, the Apollo Domain display manager and editor could (if written) be implemented on any machine with X windows. (N'est ce pas?) That is, the Apollo Domain display manager and editor are what I call a "user interface" and does not require other display managers to be excluded. My terminology is eccentric, since I would call Fortran a "machine interface." The idea is that certain software packages one would like to have available on all machines. These packages allow the users' software to be fairly independent of the hardware, hence "interface." Allow me to introduce the concept of "conventional." I use a subset of the Fortran language in order to have portable code for numerical calculations. (Crucial parts of a program may be modified to make use of vendor-specific routines.) In addition, I use some widely available non-standard features such as the "include" statement and variable names up to 31 characters long. I've learned from experience, a conventional style for writing Fortran that is portable, and also is easily optimized (vectorized) by many compilers. Also, I benefit from the decision by many compiler writers to include enhancements that are conventional though not standard, e.g. variable names of more than six characters. Am I correct in asserting that most Apollo users would agree with The Motto "better isn't better, the standard is better," when it is interpreted as a commitment to provide conventional SYS5.3, conventional BSD4.3, POSIX, PHIGS+, X Windows, PEX, and so forth? UNIX is not the main focus of this essay, but with regard to the machine interface, I'll note the following. Because so many current applications use UNIX, for many years it will be desirable for workstation vendors to implement a robust UNIX. Judging by questions on UseNet about inter-vendor portability of tar tapes and comments about the IBM RISC file locations, The Motto must be understood as implying an effort towards _conventionality_ in areas that are not fully standardized. I took a paragraph to define "conventional" because, prior to universal standardization, The Motto cannot have any meaning unless it implies an effort towards implementing things that people have found generally useful even if it not part of the standard. Am I correct in saying that most Apollo users believe the following? Applying The Motto as an argument against retaining the Apollo-style display manager and editor as an option in future operating systems (such as OSF/1) is illogical. The Motto could be used to argue against all vendor enhancements aside from speed improvements, hence one can expect The Motto to have its limits. The overall concept is this. Having a unique (or in the case of UNIX, a small number of) standards is usually desirable for what I call the machine interface. However, having several (and in some cases, many) co-existing standards is preferable for what I call the user interface. Standard user interfaces are good. I would like to transport to various platforms applications that use AVS (scientific visualization) as readily as I transport my Fortran programs. Nonetheless, I do not desire that a vendor's platform be limited to no more than one or two scientific visualization packages. (Yes, my use of "user interface" is eccentric since I am applying it to software packages. My goal is to create a conceptual _partition_ that is useful in this essay.) Specifically, a rather complete implementation of an Apollo-like display manager and editor on HP PA-RISC platforms and in OSF/1, is within the realm of user interface. Arguments against such an implementation, when based on standardization issues, are spurious. I've read some arguments saying that the Apollo display manager is better than X Windows because X is slow. X Windows seems to set back a computer by about one generation with regard to speed and with regard to whether a given cost of memory -- memory expressed in dollars rather than bytes -- is sufficient. It is important that the advantages of the Apollo display manager and editor not be thrown overboard. The speed of X Windows is separate problem. It is appropriate to expect HP to fund the porting of an Apollo-like display manager and editor to X Windows -- or in some other way make it available beyond Domain O/S. Do Apollo users agree that doing the port is simply a matter of how HP wants to spend its development funds? Do Apollo users agree that a rational approach for an evolving, standardized operating system does not counter-indicate doing the port? If one does not want to be fatalistic and passive, perhaps the following course of action is indicated. Explain to HP in detail why an Apollo-like display manager and editor is desired by a significant segment of potential buyers. Then buttress the argument by actual purchase decisions. I recall that when microcomputer chips were first introduced, each chipmaker claimed that their instruction set was "orthogonal." Analogously, the Apollo DM window system is orthogonal in a way that makes it very easy to use. It is 'of a whole' and implementing just a few features will not be enough to retain the power and beauty of the Apollo editor and window manager. For those who use the Apollo DM system, nothing more needs be said. For those who don't use the Apollo DM system, "orthogonality" is too abstract to explain its value. I've made a partial list of the Apollo DM features in Appendix A, in order to show how much it has. There may be some errors, and the list is just a small portion of all that is useful. Appendix A. ----------- I can think of more than two dozen aspects of the DM window system that are useful. I'll give a few examples. Everyone knows that a DM Standard I/O pad has an input line, but does HP know how valuable it is that the input window expands to more than one line, as needed? One can HOLD the pad and edit a series of similar commands in a multi-line input window. I've tried using an IBM RISC machine and have found their Standard I/O pad to be difficult to use. I am concerned that HP will consider something similar to the IBM offering as adequate, which it is not. The IBM RISC machines have a cut and paste feature, but the cursor can only be moved with the mouse. In the version I used, the arrow keys had no effect. Yet, I find it very difficult to delineate the region to be cut using the mouse, since one can easily miss by one row or column. All of the Apollo users I have met use the arrow keys when defining the region to be cut. Also, I find rectangular cutting and pasting to be useful, e.g. xp -r. The AGAIN key is useful for several reasons, one of which is that I sometimes have something else in the paste buffer -- it is useful that the AGAIN buffer is different. On the IBM, after pasting a line, one cannot edit the line, as far as I can tell. One can delete characters right to left, but one cannot go to the center of the line and change just a few characters. Also, the side bar on a Motif window does not seem to be as convenient as the various types of arrow keys on an Apollo keyboard. Moreover, the file name and line number at the top of any edit pad is a DM window feature that should be retained. The computer center in an adjacent building installed UseNet's "rn" (read news) on a cluster of IBM RISC workstations. The Apollo that I use happens not to have "rn". It is actually easer to use "rn" via telnet from an Apollo to an IBM RISC machine with "rn", than it is to sit down at the IBM RISC machine: because the scrolling on the IBM display is so peculiar; and because the backwards scrolling, the speed of the jump scrolling, and other DM features on the Apollo make our DN4500 easier to use for reading and grabbing text. Another very useful feature is the infinite undo. The ability to assign display manager commands to function keys has been very useful. For example, I press one function key to pop-up a dynamical display of processes: the key defines a region in which /com/dspst is run. Also, the mouse key that opens a file for reading is very useful, i.e. cv file_name. Generally, when my programs open a file, they write to standard output (which goes into a log file) the name of the file being opened. Then while reviewing the program's log file, I can click on a file name in the text and see that file. Moreover, I've redefined the key slightly so that the read window is exactly 80 lines wide. Of course, shift-SAVE will toggle to edit mode, so the mouse key is also a quick way to call-up a file to edit. The cv command is not the same as being able to click on files in a graphical display of a directory, since with Apollo DM one can click on files mentioned in any text. Though it is not the default mode on most systems, telnet can be run in the line-by-line mode rather than the character mode. On an Apollo, I find the telnet line-by-line mode very useful. The telnet session behaves almost identically to any other pad, with features such as input line editing. Though the remotely generated prompt appears in the wrong place, perhaps that can be fixed. (I have seen that when telnet is done in a crp window, the prompt does appear in the correct location.) Disclaimer: These are my opinions. Nothing herein reflects the policy of any organization. Alan Scheinine, Graduate Student email: u10534@uy.ncsa.uiuc.edu Loomis Laboratory of Physics Phone: 217-333-1065 1110 West Green Street FAX: 217-333-9819 Urbana, IL 61801