🚀 go-pugleaf

Tim Maroney raises some good points.  Before I plunge into substance,
I'd like to say something about user interfaces for the record.  [Please
note that this next paragraph expresses my *opinion*.  I am not trying
to force my views upon the world; I just want to express a contrary
opinion.]

I'm not sure that I agree that the Mac has "proven" that a menu-dialog
interface to all programs is best.  I would agree that such an
interface is easier for novice users; however, having to continually
move from the keyboard to the mouse and back again to do *anything*
on the Mac is one of the most worst features of its user-interface
for me.  I am far more productive with "vi" on UNIX than with any of
the mouse-based editors I've run across on the Mac.  Similarly, a
command-line interface (coupled with history and aliases) lets me get
my work done a lot quicker than a mouse-based interface.  I have no
use for things like "dbxtool" on the Sun -- I am considerably more
productive with the command-line interface.

User preferences vary, and I'm sure my opinion on them isn't shared
by everyone.  My point, however, is that it is not sufficient to choose
between a mouse interface and a dialog interface solely upon the type
of output device.  I would prefer a command-line interface even on a
bitmapped screen, and I suspect many other "power users" of UNIX would
also.

In addition to filters, the command-line interface to UNIX programs is
required for terminals connected by serial lines.  Bitmapped systems
are connected to standard terminals -- dialups in particular are quite
common.

So, I agree that the command-line interface to UNIX must be retained.
Now, what is the best method by which to add a visual interface?

I'd propose that a visual interface to UNIX be a separate program, not a
series of changes to individual programs.  This is consistent with the
treatment of pattern-matching in the shell -- it is performed in one place
rather than many.  It allows users to write their own visual shells.
[How many people have actually written their own command-line shell?]
It also allows a program written on one machine (e.g. a VAX) to be used
directly on (e.g.) a Macintosh.

It is unfortunate that the only interface to UNIX programs is the
untyped argv list.  At this late date, perhaps the best solution is
to define a program-interface file which specifies the names and
types of the arguments to a given program.  A visual shell would
read this file upon startup.  Programs not named would be invoked in
the traditional fashion.  (Doesn't someone's menu-based interface to
UNIX already work this way?)  When a new program is installed, the
system manager would add the interface definition to the appropriate
file.  (This could be automated as part of a "make install".)

What form should such an interface file take?  A Lisp (or Lisp-like)
definition would be the most flexible, but would presumably be more
difficult to write and might require a sizeable committment to Lisp
in the visual shell (making it large and perhaps too slow?).  A simpler
definition (perhaps expressed as a grammar with some attach semantic
information) might not be flexible enough.

We've actually discussed a lot of the issues in my group here at
LLNL because of the development of Amber (a Multics-like operating
system for our locally-designed machine).  If there is significant
interest in this topic, I'll see if I can dig up and summarize the
design decisions.  [Presently, the Amber command processor works on
cursor-addressible terminals, providing pop-up help menus, command-
filename-, and argument name-completion, and an EMACS-like line editor
for old command retrieval and editing.]
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor [jdb@s1-c.ARPA]	(415) 422-0758
  UUCP: ...!ucbvax!decwrl!mordor!jdb 	...!seismo!mordor!jdb