dpz@topaz.RUTGERS.EDU (David P. Zimmerman) (09/21/86)
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!dpzmwm@dunsel.berkeley.edu (Mike Meyer) (09/21/86)
In article <5872@topaz.RUTGERS.EDU> dpz@topaz.RUTGERS.EDU (David P. Zimmerman) writes: >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. > [Rest deleted - follow the references if you haven't seen it.] I like it. It seems to neatly bundle up the nice features of the Unix shell in a Mac-like interface. One problem is that there are 400+ commands on most Unix systems. Making all of those accessable as gadgets won't quite work. But see below on dealing with $PATH. Let me attempt to deal with some of the outstanding problems. >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. Not sure how GEM asks for them. If you're going to have an icon description, why not make it a template showing English descriptions of the options, and how to get them. The shell then maps between "Option Description Language" and gadget imagery. For example, a simple sort description would have three gadgets, one which toggled between forward and backward sorting, and one which toggled between numerical and alphabetical. The last gadget would be to go. Of course, just typing options at the command line should ALWAYS work, so the ODL interface could be added later. >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. Why? Just make each directory in $PATH a menu, and the applications in it menu entries. They can then be used just like the applications in the shell window, except you have to pick them up off the menu. This lets the experienced user get to all the Unix commands they want. >One thing we must keep in mind is that shell use and shell programming >are two different beasts. I have described shell use. I disagree. I tend to use shell history + aliases as a "small" programming language. A user doesn't have to be very sophisticated to do that. You can actually provide most of this by adding a history mechanism to your shell. Let's take the one I'm putting into MicroEmacs and see how it works in this environment. We're going to add another window to your shell, called "History." Every time the go button is hit, or something is double-clicked, the shell appends the command line it's goint to execute to the History window. When you are in the History window, it is a stock editor window, with one extra facility. You can paste text (& graphics, etc) back to the shell. This causes the shell to run the pasted commands as if they had been entered by the user. This history interface would probably be nicer than any I've dealt with before - a real editor + the ability to rerun blocks of commands. Hmmm - I think I like this interface. Now, to get someone to write it! <mike