dpz@topaz.RUTGERS.EDU (David P. Zimmerman) (09/22/86)
A discussion has been going on in net.unix over how the Mac's user
interface could be a front end for a Unix machine, since Apple has
been looking for Unix wizards but is not, repeat not, building a Unix
box (yeah, right). I posted an article which someone suggested that I
also post in net.micro.mac since it might be of interest. There have
already been replies, from which good ideas are coming. I have
included net.unix in followups to this.
------ reposting of net.unix article -------
Add another few comments into this discussion. I'd like to present a
more solid proposal for an interface instead of a theoretical one.
The present Macintosh interface could do nicely for a Unix front-end
with some work. Put the Mac screen in a full screen, resizable
window. At the bottom of the window, add a command line. Just above
the command line, have a single line of graphic gadgets symbolic of
redirection, appending, piping, etc, and "go". Add gadgets to the
window border to shove it to the back, to "cd ..", and to start a new
shell. This is your basic shell.
Assume a 2+ button mouse. In my examples, I only need 2 buttons, but
the single button of the present Mac is not enough.
This shell imitates the Finder to a certain extent. All application
icons in the current directory show up in the window. Subdirectories
are folder pictures. If it doesn't have an associated icon, use a
standard application/data file icon. The top border of the window has
the close gadget, the full-screen gadget, and the name of the current
directory. Double click with the left button to start an application
or "more" a file if it doesn't have an associated application. Click
once and pull down the menu bar for file stats, etc. This is all for
Mac compatibility. The only difference is that an application is run
in the "background", as opposed to taking up the whole machine. Sort
of like choosing "Puzzle" from the Finder apple menu. Every
application will have its name at the top of its window, a close
gadget, and a "shove-to-back" gadget ("stdout" - see below).
Click once with the *right* button and watch a picture of the icon
show up in the command line at the bottom. Redirection and piping can
be specified by clicking an appropriate gadget with either button.
Click "go" to make it go. "go" can also be done by double-clicking
the right button on the last application in the chain, or pressing
RETURN. Of course, you can type in filenames and whatever you want in
the command line. With this, you could theoretically run "who" and
pipe it through grep and more without touching the keyboard.
I am tempted to deal with command-line options like GEM does - specify
in the application icon/description whether it needs options. If it
does, ask for them. Of course, in specifying the options you could
use redirection and such with the appropriate gadgets.
Trashcan sits on the desktop (not inside any window). Standard use.
Empty it with "Empty trash" under "Special" menu bar option.
The menu bar will have apple on it, as well as the File, Dir, Edit,
View, and Special. File would have chmod, chown, more, ln and other
goodies. Dir would have cd, rmdir, mkdir, other dir stuff. Edit
would have the Cut, Copy, and Paste, as usual. View would let you
view the files one of many ways - only applications, only current
directory, whole path, by icon, by small icon, by speck icon :-), by
name, etc. Special would have empty trash, man, shutdown, and other
fun miscellaneous stuff.
Stdout by default goes to a window titled "<application>" as mentioned
above. In a chain, <application> will be the last program in the
pipe, since the final output is coming from it. Stderr is the same,
but <application> will be of the form "<application-1>|...|<application-n>"
with the applications in between replaced by "|...|" for conservation
of space.
One thing we must keep in mind is that shell use and shell programming
are two different beasts. I have described shell use. Shell
programming wouldn't be much different from a normal Unix box, except
for graphics extensions. Shell programming isn't hindered by any of
my MacUnix interface (I don't think) - you still write your script
with vi/Emacs/whatever and chmod it executable.
Comments? A problem I see right away is that, say, piping a program
in /bin to a program in /usr/local/bin, without using the keyboard,
involves a lot of directory hopping with the mouse. Possibly a
different way of Viewing the programs would help.
Always in search of a better user interface...
David
--
David P. Zimmerman "Unix RULES!!!" - anonymous
Arpa: dpz@topaz.rutgers.edu
Uucp: ...{allegra | harvard | seismo | sri-iu | ut-sally}!topaz!dpz