gwe@cbdkc1.UUCP ( George Erhart x4021 CB 3E373 DEBR ) (09/12/86)
I am currently involved in a second try to port Dave Betz' SDB (Simple
DataBase) to the Mac. The first try was using Megamax C and it was
far from successful. The second is with LightSpeed C and it too
is having problems.
My plan was to port the UNIX version straight out, get it running, and then
convert it into a Mac Application. (You know ... menus, dialog boxes, fonts,
etc ...) Unfortunately, it appears that most Mac C compilers do not come
with very good libc.a implementations. The one for MegaMax was full of
bugs. I am still having random crashes in the token parsing stuff from
the LSC version.
Does anyone else have any comments or experience with this kind of porting?
--
George Erhart at AT&T Bell Laboratories Columbus, Ohio
614-860-4021 {ihnp4,cbosgd}!cbdkc1!gwetim@hoptoad.uucp (Tim Maroney) (09/15/86)
This issue is going to become more and more important as the UNIX Mac is
released. Apple has committed themselves to preserving the Mac interface
while also supporting UNIX(tm). But my gremlins (actually, experience with
the Mac Programmer's Workshop) report that they don't really have a complete
or general paradigm for doing this yet. I'd like to see some discussions on
how this ought to be done.
Briefly, the problem is this. On the Mac, all user applications are graphic
applications. On UNIX, very few applications use graphics beyond those
attainable on a hardcopy character-graphics terminal. While the flexibility
of the UNIX system for an expert programmer has never been approached by any
other operating system, it is notoriously unfriendly and mystifying to naive
users. This is too bad, because many of its applications, such as grep,
would be very useful to any user at any level of experience.
Most bitmapped UNIX systems just ignore the problem and pretend that it is
sufficient to use bitmapped output devices to provide multi-window terminal
emulators. The Mac shows that this is not true, that for user interfacing
every application should be a graphics application, that the presentation of
options to the user as controls and menu items achieves much more user
friendliness. But this leaves open the issue of integrating the existing and
extremely high-quality UNIX system into the Mac's graphics-intensive
environment.
To make matters worse, it is impossible to just change the applications to
use a bitmapped user-friendly interface. One of the great strengths of UNIX
is the ability to create multi-process programs, even on the fly, by using
pipes and i/o redirection to chain together multiple programs. This is made
possible only because of the use of a character-stream, non-graphics
interface for most applications. If this is lost, then no way is it UNIX.
But if it is retained as a user interface, no way is it either Mac-like or
novice-friendly.
To take a concrete example, the grep program provides an extremely useful
search facility. On the Mac, it should be a dialog box allowing
specification of a range of files to search (using an extended standard file
interface) and a regular expression to search for, with help windows to
explain the use of regular expressions. If this is the only interface, it
becomes impossible to use grep in multi-process programs. So it would
appear that both interfaces need to be retained, but in different contexts;
and this is true not only of grep, but of most other applications as well.
There seem to me to be two basic options for solutions to this problem (or
to put it in the usual jargon, this is the top level of the decision tree).
First, we may modify the existing UNIX applications. Second, we may make
some sort of separate input/output filter for each application. In either
case, we need some way of detecting the type of the input, output, and error
channels, which may be tty (or pseudo-tty) windows, pipes, files in the file
system, or bitmapped i/o systems. A simple ioctl will suffice for this
purpose. In the first solution, the type checking is done by the
application itself; in the second, it is done by the "shell" (which would
presumably be something like Servant).
It seems cleaner to me to set up separate i/o filters, although this would
probably increase system overhead. It is possible that some specification
language for such i/o filters could be created that would obviate the need
to write a C program for filtering and also not require that a separate
process run to mediate between the program and the user. Hacking the UNIX
applications themselves seems like a much bigger job, and one that would be
likely to introduce new bugs into the applications, which at this point are
fairly well-tested and bug-free.
Any other ideas on this subject?
--
Tim Maroney, Electronic Village Idiot and Self-Assigner of Pretentious Titles
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)
"Little people, with tiny brains; little bullets flowing in their veins!
What do they want? They want you!" - Oingo Boingo, "Tiny Guns"mlandau@Diamond.BBN.COM (Matt Landau) (09/15/86)
In article <1091@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >Briefly, the problem is this. On the Mac, all user applications are graphic >applications. On UNIX, very few applications use graphics beyond those >attainable on a hardcopy character-graphics terminal. > >To make matters worse, it is impossible to just change the applications to >use a bitmapped user-friendly interface. One of the great strengths of UNIX >is the ability to create multi-process programs, even on the fly, by using >pipes and i/o redirection to chain together multiple programs. This is made >possible only because of the use of a character-stream, non-graphics >interface for most applications. There was a very interesting presentation at this year's Summer Usenix on communicating data between processes in different windows existing in a graphical user environment. It was called "A Data-Flow Manager for an Interactive Programming Environment", and was given by Paul Haeberli of Silicon Graphics. The accompanying paper may be found in your local copy of the 1986 Summer Usenix Proceedings. The system amounted to a way to pipe data between graphical manipulation and display programs, and provided a user-interface that made specifications of input and output sources easy (lines and arrows, etc.) -- Matt Landau BBN Laboratories, Inc. mlandau@diamond.bbn.com 10 Moulton Street, Cambridge MA 02238 ...harvard!diamond.bbn.com!mlandau (617) 497-2429
jdb@mordor.ARPA (John Bruner) (09/15/86)
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
wetter@tybalt.caltech.edu.Caltech.Edu (Pierce T. Wetter) (09/16/86)
In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes: > I am far more productive with "vi" on UNIX than with any of >the mouse-based editors I've run across on the Mac. Ha Ha Ha Ha Ha Ha Ha Ha HaHa Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Ha Considering my experiences with vi (holding the up/down/left/right keys causes some versions to delete random snatches of text) this is the most hilarious thing i've ever heard. When I'm programming the thing I do most often is move around in the file. You cant tell me that pointing and clicking with the mouse isn't faster then banging away on random cursor keys. It's true that you can go directly to a specific line number but you can't easily go up five lines and over twenty characters. Also a mouse based editor is much easier to cut & paste in (which if you looked at code I've written you'll know why I like this--" Who needs a for next loop I'll just paste it in five times") Also, you need to move your hands away from the "home row" whenever you hit the escape key or any other "control key". The mouse isn't any worse ( unless you have an infinate typing speed). However, there is one small thing I should mention, I'm using a trackball instead of a mouse (desk space Yay!!!!!!!). If you are using a mouse on a towel (yucky surface) I might believe you but otherwise. Snicker Snicker... Nuff Said Pierce wetter
gaynor@topaz.RUTGERS.EDU (Silver) (09/16/86)
Pierce T. Wetter (...!tybalt.caltech.edu!wetter) writes: > Ha Ha Ha Ha Ha Ha Ha Ha Ha > Ha Ha Ha Ha Ha Ha Ha Ha Ha > Ha Ha Ha Ha Ha Ha Ha Ha Ha I think it's just this kind of discussion that John Bruner was trying to avoid when he expressed a preference, with all the disclaimers that he was expressing his opinion. Although I myself would enjoy hearing your (netwide) opinions on the subject of user interfaces, I wouldn't want to read them hear. It is enough to say, "The interfaces Foo, Bar, Bletch-II, and even Bletch are popular, and will have to be considered in this discussion.". Discussions of their relative merits is better held in, oh, probably net.cog-eng (or if there's a talk.interface going...). Just trying to nip a heated-argument-that-doesn't-belong-here in the bud, Silver. Silver (argyros (greek), argentum (latin)) Silver is the whitest and most reflective of the metals, also having the highest thermal and electrical conductivity. It is second only to gold in malleability and ductility. name: Andy Gaynor e-address: ...!topaz!gaynor address: 19 Evergreen Drive, Denville, 7 Raven Drive, Morristown phone: 627-8953, 267-8660 atomic symbol: Ag atomic number: 47 atomic weight: 107.88 isotopes: 107 (0.5135), 109 (0.4865) melting point: 950.5 C boiling point: 1950 C density: 10.49 hardness: 2.5 - 3.0
dave@onfcanim.UUCP (Dave Martindale) (09/16/86)
In article <816@Diamond.BBN.COM> mlandau@slate.BBN.COM (Matt Landau) writes: > >There was a very interesting presentation at this year's Summer Usenix >on communicating data between processes in different windows existing >in a graphical user environment. It was called "A Data-Flow Manager for >an Interactive Programming Environment", and was given by Paul Haeberli >of Silicon Graphics. The accompanying paper may be found in your local >copy of the 1986 Summer Usenix Proceedings. The system amounted to a >way to pipe data between graphical manipulation and display programs, and >provided a user-interface that made specifications of input and output >sources easy (lines and arrows, etc.) The great thing about this is that it allowed you to set up arbitrary data-flow graphs, not just pipes. This is important for interconnecting 3D graphics tools, since one program may have several "inputs". What it does *not* do is allow you to set up a straight pipeline, the most common form of parallelism in UNIX, as fast as just typing '|'. One of the nice things about UNIX is the rapidity with which you can put together "paste x y z | egrep pattern | sort | awk 'commands'". To do this while staying in the MAC user interface model would require that the shell be made into a graphics program, with some sort of graphical way of building all of the constructs that you can currently do with a command line. Now, a graphical tool for building pipelines isn't too hard to imagine. But the shell (any of them) is actually a quite powerful programming language, and I find it hard to imagine a graphical tool with all the flexibility of the shell (loops, conditionals, background processes, argument processing) that would not be incredibly clumsy to use, just because of all the possible choices. So, a question: If you had the best programming team in the world available, able to implement any consistent design you came up with, how *would* you design a shell?
bill@utastro.UUCP (William H. Jefferys) (09/16/86)
In article <981@cit-vax.Caltech.Edu>, wetter@tybalt.caltech.edu.Caltech.Edu (Pierce T. Wetter) writes: > In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes: > > I am far more productive with "vi" on UNIX than with any of > >the mouse-based editors I've run across on the Mac. > > Ha Ha Ha Ha Ha Ha Ha Ha HaHa Ha Ha Ha Ha Ha Ha Ha Ha I am in 100% agreement with this. In my opinion, vi is the *worst* screen-oriented editor that I have ever had the misfortune of using. I am always finding new "features" that I wasn't aware of. Unfortunately, the new features I discover usually wipe out random pieces of text in mysterious ways that are difficult to reverse. It all comes of trying to make "ed" look like a screen editor. What a kludge! -- Glend. I can call spirits from the vasty deep. Hot. Why, so can I, or so can any man; But will they come when you do call for them? -- Henry IV Pt. I, III, i, 53 Bill Jefferys 8-% Astronomy Dept, University of Texas, Austin TX 78712 (USnail) {allegra,ihnp4}!{ut-sally,noao}!utastro!bill (UUCP) bill@astro.UTEXAS.EDU. (Internet)
len@geac.UUCP (Leonard Vanek) (09/16/86)
In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes: > >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. > The above point leads me to wonder about the use of the two editors that come with the Mactintosh version of the Aztec C compiler. How many users of Aztec C (or any other Mac compiler that offers the choice) use the vi-like Z editor or the mouse-based Edit? I personally agree with John, that both options should be retained -- regardless of the hardware. In fact, we at Geac are designing a user interface that will have that very property. We are trying to arrange it so that it is not necessary to choose a priori which mode a user is operating in, but allow the user to switch between input modes depending on how easy each request is to express in each of the modes. Len -- --------------------------------------------------------------------- Leonard Vanek phone (416) 475-0525 Geac Computers International 350 Steelcase Rd. West USENET ... !utzoo!yetti!geac!len Markham Ontario L3R 1B3 Canada Note: My Usenet path is subject to change on short notice!
mwm@eris.berkeley.edu (Mike Meyer) (09/17/86)
In article <981@cit-vax.Caltech.Edu> wetter@tybalt.caltech.edu.UUCP (Pierce T. Wetter) writes: >In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes: >> I am far more productive with "vi" on UNIX than with any of >>the mouse-based editors I've run across on the Mac. > > Considering my experiences with vi (holding the up/down/left/right keys >causes some versions to delete random snatches of text) this is the most >hilarious thing i've ever heard. Which just goes to show that you haven't much experience with vi. >You cant tell me that pointing and clicking with the mouse isn't faster >then banging away on random cursor keys. Actually, I can. Somewhere I've got a paper describing a study done on editor interfaces, and it turns out that the fastest interface - in general - is a foursome of arrow keys plus function keys. Second is an emacs-like interface (vi wasn't in the study), and third is the mouse. Finding the mouse seems to be the killer. >It's true that you can go directly to a specific line number but you >can't easily go up five lines and over twenty characters. Also a mouse >based editor is much easier to cut & paste in (which if you looked at >code I've written you'll know why I like this--" Who needs a for next >loop I'll just paste it in five times") Being an emacs user, the thing that I most like about the mouse interface is the ability to bounce to text in another window without worrying about changing windows. But this is why my Amiga emacs has 24 bindable mouse buttons; so I can get LOTS of mouse functionality when I start using it. I move between the two modes regularly. Of course, cut in paste with or without the mouse is equally hard: go to one end, mark, go to the other end, cut. The only real difference is the moving. It's easier to do all this with whatever my hands are on, be it the mouse or the keyboard. > Also, you need to move your hands away from the "home row" whenever you >hit the escape key or any other "control key". Hmm. Seems that the ESC key on my Sun is easily reachable by the ring finger of my left hand. In fact, I hit the F1 key (caps lock) above it so often that I set it up to be an ESC key also. Of course, I have big hands. <mike
mac@esl.UUCP (09/17/86)
In article <981@cit-vax.Caltech.Edu> wetter@tybalt.caltech.edu.UUCP (Pierce T. Wetter) comments on what John Bruner writes: >In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes: >> I am far more productive with "vi" on UNIX than with any of >>the mouse-based editors I've run across on the Mac. > > Ha Ha Ha Ha Ha Ha Ha Ha HaHa Ha Ha Ha Ha Ha Ha Ha Ha >Ha Ha Ha Ha Ha Ha Ha Ha Ha I use "cat | cc -O " myself. -- ------------------------------------+-----------------------------------------+ | Michael Mc Namara | MM MM MM OO SSS AAA II CCCC | | ESL Incorporated | M M M O O S A I C C | | ARPA: mac%esl.UUCP@ames.ARPA | M M M O O SSS AAAA I C | | mac%esl.UUCP@shasta.ARPA | M M M O O S A A I C C | | mac%esl.UUCP@lll-lcc.ARPA | MM M M OO SSS AAA A III CCCC | ------------------------------------+-----------------------------------------+ | Note: esl used to be called tflop; the path mac%tflop will still work awhile| ------------------------------------+-----------------------------------------+
rb@cci632.UUCP (Rex Ballard) (09/17/86)
In article <1091@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >This issue is going to become more and more important as the UNIX Mac is >released. Apple has committed themselves to preserving the Mac interface >while also supporting UNIX(tm). But my gremlins (actually, experience with >the Mac Programmer's Workshop) report that they don't really have a complete >or general paradigm for doing this yet. I'd like to see some discussions on >how this ought to be done. > >Briefly, the problem is this. On the Mac, all user applications are graphic >applications. On UNIX, very few applications use graphics beyond those >attainable on a hardcopy character-graphics terminal. The problem is a difference in concept. Unix creates a "stream of bytes" which can be treated as a "stream of bytes" OR a "stream of objects". In Unix, common objects include letters, words, lines, paragraphs, and pages. Applications of various "classes" such as find, sort, grep, and awk, are actually subsets of the same type of record. The important factor here is that information that may be part of a larger set of classes, can be extracted for use by smaller class operators. C source can be "grepped" for comments that can be manipulated by "awk" into information that can be used by sort, join, lorder, find, and other "delimited field objects". The Mac currently supports the concept of a "Stream of Objects", but objects are often defined and remain unique to the application which creates them. A "box" in MacProject may be quite different than a "box" in MacDraw or MacPaint. The clipboard and scrapbook are capable of supporting a subset of these objects, but the ability to transform objects is not considered mandatory to the application. Such transforms are not impossible. Other systems, which at least emulate the Mac user interface, also define a standard set of objects, with the capability for extensions. Postscript has this capability as well. VDI type interfaces are a key element. A full VDI interface can take "standard input" from a mouse/keyboard, or file, and display it to a "bit-map screen", an "ACRTC device", a Laser Printer, or a disk file, without knowing or caring which device is the output, or where the output will go. It may be possible to for example "grep" for "boxes containing text pattern", but only if "boxes containing text pattern" are defined in a standard way, such as group(box(x1,y1,x2,y2),text(x,y,string)). Parsing of these groups and object streams requires an actual parser, but should be possible, even simple to do. A good test of such a parser would be to output in "human-readable text form" any input file in "standard stream of objects file", and have the "human readable form" become input to a parser which will convert it back into "stream of objects" form. Now you can put standard text filters, as well as "stream of object" filters between the to resources. Another concept that is important is that of "strings" as well as "packets". Packets require that you know about certain information inside the packet (such as number of objects, length in bytes,...) before the packet can be sent. Strings simply require an "end of string" delimiter. A simple object of this type could be added to the existing archetecture and would enable creation of objects larger than the storage space available, very important when only parts of a collection are needed. >While the flexibility >of the UNIX system for an expert programmer has never been approached by any >other operating system, it is notoriously unfriendly and mystifying to naive >users. This is too bad, because many of its applications, such as grep, >would be very useful to any user at any level of experience. This is a valid point. A few new products, such as Office-Power, GNU Emacs, VSH, and a large assortment of other "visual shells" have made good progress in this direction, but are most often limited by the weaknesses of the "terminal interface" rather than the archetecture. Building "classes" of operators is more difficult, but not impossible. The object oriented design, rather than object oriented language, is all that is often needed. >Most bitmapped UNIX systems just ignore the problem and pretend that it is >sufficient to use bitmapped output devices to provide multi-window terminal >emulators. The Mac shows that this is not true, that for user interfacing >every application should be a graphics application, that the presentation of >options to the user as controls and menu items achieves much more user >friendliness. It is true, to a point, that each application should have a "graphics interface" on the front end. But it is also appropriate to have one of the options be "text arguments", or function keys. In addition, the hierarchy of menus could be three dimensional, or even deeper. For example, the top line options might change as the various options are scanned, allowing search of say 64 options using a simple 8x8 matrix, of which only the options for the given menu selection are given. >But this leaves open the issue of integrating the existing and >extremely high-quality UNIX system into the Mac's graphics-intensive >environment. Try to think of it this way, the best part of UNIX is it's "back end" or "application to application data compatibility". The best part of Mac (most of the time) is it's "front-end" intuitive graphics user interface. >To make matters worse, it is impossible to just change the applications to >use a bitmapped user-friendly interface. One of the great strengths of UNIX >is the ability to create multi-process programs, even on the fly, by using >pipes and i/o redirection to chain together multiple programs. This is made >possible only because of the use of a character-stream, non-graphics >interface for most applications. If this is lost, then no way is it UNIX. >But if it is retained as a user interface, no way is it either Mac-like or >novice-friendly. How about the ability to "draw circuits" of pipelines and filters for "batch type jobs". In fact, "tees" could get very interesting. A "data flow diagram" with prompts for each member of the circuit could also be useful. If input format and output format could be specified, it might even be possible to normally restrict "next in chain" options to those commands which create/use the appropriate format. Of course, it should be possible to enter text stream commands at some level as well. As mentioned before, byte-streams and graphics DATA interfaces are not necessarily mutually exclusive. Conversely, character interfaces and character streams are not necessarily mutually inclusive. Try putting a "pipe" between your standard input and VI if you need convincing. A "pipe" between VI and standard output might actually be useful (VI would only need one definition of "termcap" and a "curses interface" similar to those used by plot, could do the conversion to specific terminal codes). For editors, it might not be necessary to have "streaming" capability, proprietary formats, during the actual editing, might also have legitimate use (VI and various other interactive editors put the proprietary format file in /tmp or /usr/tmp, often under a process id type configuration. The only special need is that the final product be either saved or convertable to, a "standard data interface format". >To take a concrete example, the grep program provides an extremely useful >search facility. On the Mac, it should be a dialog box allowing >specification of a range of files to search (using an extended standard file >interface) and a regular expression to search for, with help windows to >explain the use of regular expressions. So far, not really a problem. I can generate '>grep 'object >' using either a text specification, or a visual interface which creates the text specification. If you wanted to be really perverse, you could set up binary "argv, argc, and env", but that may be and extra step. >If this is the only interface, it >becomes impossible to use grep in multi-process programs. Only if you begin execution immediately. Your "shell" parses for a complete command in unix, your "Mac Shell" could wait until you pressed an "O.K." dialogue box for the "Shell Command". The command(s) which make up the stream could be done as picture drawings, even with a "save" feature. If you wanted to make it real interesting, you could "display" text mode input versions. >So it would >appear that both interfaces need to be retained, but in different contexts; >and this is true not only of grep, but of most other applications as well. For matters of taste, this is true, but again, the two can compliment rather than conflict with each other. >There seem to me to be two basic options for solutions to this problem (or >to put it in the usual jargon, this is the top level of the decision tree). >First, we may modify the existing UNIX applications. If you mean, modify the actual method "grep" uses for parsing it's arguments, this may not be necessary. In reality, you need a hybrid between the "shell" and the "man" to create a visual shell that can create "standard exec and popen" type calls for the shells. >Second, we may make >some sort of separate input/output filter for each application. Again, transforming from one common form to another is not out of the question. This however does not need to be done in each application. >In either >case, we need some way of detecting the type of the input, output, and error >channels, which may be tty (or pseudo-tty) windows, pipes, files in the file >system, or bitmapped i/o systems. This is the "magical" feature of VDI. What you will need is drivers which use the standard "Virtual device" format, and transform tasks to convert from one type to the other, hopefully in a "per object" mode. Editors should issue VDI calls directly (the same way they issue quickdraw calls, but implementation of quickdraw calls rather than use of them become device dependent. In other words if you. fd1=fopen("window","w"); fd2=fopen("diskfile",w); box(fd1,x,y,x2,y2); box(fd2,x,y,x2,y2); the second box command might simply be a write of whatever the token for "box" was and the binary co-ordinates. So long as all applications agree on one definition of "token for box", your all set. Applications that didn't use the standard set would have to provide the transforms to AND from their proprietary format to at least one of the "general purpose" formats. Apple would be responsible for transforming from one "general purpose" format to another. For example "scrapbook to postscript" and "postscript to scrapbook". >A simple ioctl will suffice for this >purpose. In the first solution, the type checking is done by the >application itself; in the second, it is done by the "shell" (which would >presumably be something like Servant). An important factor here is that the input type and output type of not only the files, but also the applications must be available to the shell. >It seems cleaner to me to set up separate i/o filters, although this would >probably increase system overhead. This is one option when two applications have incompatible formats. In this case it might be necessary to have two transform filters. For example MacDraw.Print GCCfile |MacDraw.to_scrap |MacWrite.from_scrap|MacWrite.grep|\ MacWrite.to_vdi|Laserwriter Yes this is extra overhead, but it might not be necessary to do it often. This might be used to extract a small portion of the file. The important thing here is that A) only a portion of the application needs to be running, B) The user isn't required to remember where in the sequence he is when he takes a break (with data stuck in the scrap). He can also do something else while waiting. >It is possible that some specification >language for such i/o filters could be created that would obviate the need >to write a C program for filtering and also not require that a separate >process run to mediate between the program and the user. BINGO!!! Apple already has three possible specifications, subsets and supersets could be added, possibly even by the "install" of running and application (sounds more like OS-9 all the time). >Hacking the UNIX >applications themselves seems like a much bigger job, and one that would be >likely to introduce new bugs into the applications, which at this point are >fairly well-tested and bug-free. You may want super-graphics versions of certain types of filters, but it is probably a good idea to keep the UNIX versions as-is. One of the advantages of doing text-mode formats, is that humans are excellent pattern recognisers. They can often identify a pattern which would not be obvious to the computer, the parser, or the user, when only binary modes are available. >Any other ideas on this subject? >-- >Tim Maroney, Electronic Village Idiot and Self-Assigner of Pretentious Titles There are a few, hopefully constructive ideas, for getting the best of BOTH UNIX and MAC features, without giving up too much of either. Rex Ballard.
rae@unicus.UUCP (Clith de T'nir) (09/17/86)
In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes: >... I would prefer a command-line interface even on a >bitmapped screen, and I suspect many other "power users" of UNIX would >also. In article <137@geac.UUCP> len@geac.UUCP (Leonard Vanek) writes: >The above point leads me to wonder about the use of the two editors that >come with the Mactintosh version of the Aztec C compiler. > >I personally agree with John, that both options should be retained -- >regardless of the hardware. > >.. allow the user to switch between input modes depending on how easy >each request is to express in each of the modes. When using Aztec C, one may run a Mac program specifying arguments which must be valid filenames (equivalent to selecting these files as icons together with the application and then double-clicking). Now, we could adapt mac programs fairly painlessly to Unix by allowing any series of strings, not just filenames, to be passed to applications. Thus from the Unix side, Mac programs would be fairly painless to use. Now as for the Mac side, how do we pass strings to programs? In the Finder/ Servant, perhaps one could click in the middle of whiteness, creating a text item, a la MacDraw/MacPaint, and then select that along with the program before double-clicking. For pipes, they would use resources rather than straight text. For Unix programs, these would always be TEXT resources, but this need not be the case for other programs. Hopefully someone more intelligent than I might think of a way to do this in a painless way so that no extra setup would be required by the Unix programs like diff, grep etc. (ie no rewriting of code!)... As for aliases/shell functions, there should be an artifact that would be called a "Proxy Icon" that is basically a symbolic link to a real icon. Then these proxies and text items could be grouped and either put in a folder or merged into a special icon that, when double-clicked (or perhaps command- or option-double-clicked in the case of the folder) runs as if the text and the given application were double-clicked. A bit long-winded, but I hope you get the idea.. Please feel free to tell me how foolish I am (preferable in reasonable terms :)) -- "My surname is Li and my personal name is Kao, and there is a slight flaw in my character." Reid Ellis, aka Clith de T'nir {decvax,allegra,ihnp4,pyramid}!utzoo!utcs!yetti!unicus!rae or... seismo!mnetor!yetti!unicus!rae
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/17/86)
UNIX implies all sorts of stream commands and their combination via pipes. This implies some sort of shell, unless you can think of a way to create such constructions from a window enviroment. It may seem simply enough to state 'everything can be made user friendly', but it isn't practical for EVERYTHING, especially UNIX related things. The reason VI and EMACS are so popular is simply because they can do anything you want them to do. You can fit only so much in a menu-based system (and going to many levels of sub-menu's means the user can no longer do operations 'with a flick of his mouse button'). UNIX was originally and still is a programmer's development enviroment. -Matt
dubois@uwmacc.UUCP (Bill Winkle) (09/18/86)
>>> I am far more productive with "vi" on UNIX than with any of >>> the mouse-based editors I've run across on the Mac. >> Ha Ha Ha Ha Ha Ha Ha Ha HaHa Ha Ha Ha Ha Ha Ha Ha Ha > I am in 100% agreement with this. In my opinion, vi is the *worst* > screen-oriented editor that I have ever had the misfortune of using. > I am always finding new "features" that I wasn't aware of. Unfortunately, > the new features I discover usually wipe out random pieces of text > in mysterious ways that are difficult to reverse. My experience is different. The new things I find out about periodically are useful to me. Vi is, for me, a productive editing environment, so much so that I regularly write programs with it and then send the stuff to my Mac for compiling and debugging. And when I know I'm going to make a lot of changes, I send it back to the Vax. More general comment: It's true that mouse-based editors make it easier to perform some of the motion commands (e.g., 3 lines up, 20 characters left). But isn't it true that it's easier to perform other motion commands with keystrokes (e.g., move to the top or bottom of the screen)? Mac users (some of 'em, anyway) like to talk about modeless operation, but let's not forget: the mouse *IS* a mode. Modelessness is a myth, propagated sometimes by people who should know better. -- Paul DuBois UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois | ARPA: dubois@easter --+-- | "If it works, I didn't write it." |
emv@umix.UUCP (Edward Vielmetti) (09/19/86)
In article <267@uwmacc.UUCP> dubois@uwmacc.UUCP (Bill Winkle) writes: >Mac users (some of 'em, anyway) like to talk about modeless >operation, but let's not forget: the mouse *IS* a mode. Actually the Mac mouse interface is highly modal. The meaning of a mouse click depends entirely on where you are on screen. MS Chart used to (still does? don't know) switch cursors every time the meaning of a mouse-click changed. Run that thing over a chart and the cursor would change 5, 10, 15 times. Edward Vielmetti, U-Mich Computing Center, ihnp4!umich!umix!emv emv@umix.cc.umich.edu
tesler@apple.UUCP (Larry Tesler) (09/19/86)
In article <267@uwmacc.UUCP> dubois@uwmacc.UUCP (Paul DuBois) writes: >Mac users (some of 'em, anyway) like to talk about modeless >operation, but let's not forget: the mouse *IS* a mode. > >Modelessness is a myth, propagated sometimes by people who should >know better. If I can figure out how to use vi, I'll reply. I agree that modelessness is a technically vague term. It could be argued that even a text editor like MacWrite has one mode, "obey-next-input mode". But if a program has one mode, it has no mode changes, and thus we call it modeless. It is also arguable that a font change command produces a mode, but so does a caps lock key; I call either a "shift", which, as modes go, is innocuous because the effect of forgetting which mode you are in is certainly less drastic than that of typing "23d Street" without first entering insert mode in vi. Depending on how you choose to define "mode", the mouse could be called a mode, but then so could the "7" key on a typewriter. A useful definition of mode is a state of a user interface that affects the interpretation of subsequent inputs without obvious indication. It is possible on the Macintosh, using clover keys, to bring up a dialog box and thus enter a mode unknowingly. But it is exceedingly rare compared with systems like vi that overload the typing keys with functional meanings. Let me add that, although I agree vi is an obnoxious editor, I do think it deals with the mode problem gracefully. Bad keystrokes often beep, undo is always available for one command, and most vowels enter insert mode so it is difficult to type a word as a command. Modelessness is not a myth. Like "seamlessness" or "painlessness", it is an ideal that may rarely be attainable but is always worth approximating. The alternative is surely inhumane computing. Larry Tesler, Advanced Development Group, Apple Computer, Inc. The opinions expressed above are my own although I suspect more than a few colleagues, not to mention users, would substantially agree with them.
tim@ism780c.UUCP (Tim Smith) (09/19/86)
In article <305@esl.UUCP> mac@esl.UUCP (Mike McNamara) writes: > > I use "cat | cc -O " myself. On what UNIXs does this work? Most cc's that I have seen will not take stdin. To get the desired results, I have always had to do this: ln /dev/tty /dev/tty.c cc -O /dev/tty.c # damn thing wants a ".c" file! -- What's the difference between a duck? Tim Smith USENET: sdcrdcf!ism780c!tim Compuserve: 72257,3706 Delphi or GEnie: mnementh
shaddock@rti-sel.UUCP (Mike Shaddock) (09/19/86)
In article <1091@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >This issue is going to become more and more important as the UNIX Mac is >released. Apple has committed themselves to preserving the Mac interface >while also supporting UNIX(tm). But my gremlins (actually, experience with > > [lots more good information here, but trimmed for brevity ]. Tim brings up good points on the problems of i/o re-direction on the Mac. It seems to me that most logical place to do this would be in the stdio routines. If we could change the stdio routines to do our type checking, simply recompiling the program on the Mac would get it running. I may be missing the point, but it sounds like there are two problems, one involving putting a Mac interface on grep (for example), and one to do the actual i/o stuff. As far as putting a Mac interface on the program, I think that it would not be very hard to do for most programs. A subroutine at the beginning of the program which handles the window stuff to set up the parameters, files, regexp's, etc., then you pick something to start the program to actually "run" (for grep, to start searching). Two other things bother me, though. One, how do we tell a program to redirect its i/o in the first place, and two, how do we handle all of the many different programs from Unix(tm)? I suppose that we could have some sort of menu that says "I want to run some programs piped together", and then pick the programs in the appropriate order, or we could do what was done for the Amiga in the CLI interface (i.e. have something like a shell window where you use the standard Unix syntax), and then let each program pop up a window for it use. For the second problem, Unix(tm) has the "path" concept, but how do we do this on a Mac? We don't want to have lots and lots of program icons littering the desktop, and we really don't want to have extremely long menus of commands. Does this sound like a valid problem, or am I just confused? -- Mike Shaddock {decvax,seismo,ihnp4akgua,philabs}!mcnc!rti-sel!shaddock "You're in a twisty maze of sendmail rules, all obscure."
ir450@sdcc6.ucsd.EDU (ir450) (09/20/86)
To add to the mouse vs vi editors debate, I will tell my story. At work I use this nice SUN workstation, and I use the mouse only to switch between screens, and evry so often, I will cut and paste with it. I use only vi on this system (4.2) and I can quickly and easily produce anything I need. At home I have an Apricot running MS-DOS and GEM. It takes average 4 hours to write and perfect a simple one page letter using its mouse based editor. It takes forever to find anything in the letter, and almost that long to move through the letter. I also hate having to move my hand from the mouse to the keyboard continually. I have NEVER had ANY experience with vi removing text and doing the wierd things that the previous posters have stated, even when I was a beginner with vi. It has ALWAYS been the best editor I have used. I think the reason for this is that you can use whatever level of expertice you want. If you are a begineer with it, you just have to know how to insert, delete and save a file. With other editors I have tried to use, you must know almost everything about it, just to get started. Except of course for mouse based editors, which tell you nothing and give the begineer no useful features. Obviously, I have used the vi editor to write this followup, and I can tell you that I had no problems doing so. Brian Keves ARPA: keves%ra@sdcsvax.ucsd.edu Lab for Math and Stats UUCP: sdcsvax!ra!keves UCSD, La Jolla, CA PHONE: 619-450-6421 Any opinions expressed are my own and are not the opinions of my employer. -- Brian Keves ARPA: keves%ra@sdcsvax.ucsd.edu Lab for Math and Stats UUCP: sdcsvax!ra!keves UCSD, La Jolla, CA PHONE: 619-450-6421 Any opinions expressed are my own and are not the opinions of my employer.
db@cbosgd.UUCP (Deceased Bird) (09/20/86)
In article <137@geac.UUCP> len@geac.UUCP (Leonard Vanek) writes: >In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes: >> >>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. >> >The above point leads me to wonder about the use of the two >editors that come with the Macintosh version of the Aztec C >compiler. > >How many users of Aztec C (or any other Mac compiler that >offers the choice) use the vi-like Z editor or the >mouse-based Edit? > I use the Z editor -- in fact, it's one of the reasons I bought Aztec C. Although I'm not entirely thrilled with vi, I'm used to it and can live with it. I haven't used Edit much at all but I do use MacWrite regularly, mainly for correspondence but also for memos. Switching between mouse-based editing and a 'traditional' screen editor has made me rather schizo. It never fails that I'm in Z, want to delete a large block of text, and reach for the mouse to select the text. Conversely, while in MacWrite I often enter an (pseudo) ESC in an attempt to terminate text entry or try to move backwards using 'b' or '-'. I do like having the choice of environments, but I would like an 'integrated' (i.e., both pointer and command) environment even better. The examples I cited above illustrate the respective strengths of each interface and suggest ways in which each could be exploited to compensate for the weaknesses of the other. I also like having the Aztec shell available on the Mac. The simultaneous menu and command-line interface is a simple example of an integrated environment which is handy to use, especially the compilation menu (does away with the need for compile/asm/link scripts for simple programs). The main problem with the Aztec shell is that it's not really UNIX -- it can be quite frustrating not being able to form pipelines, spin off background processes, etc. Considering that it is a simple Bourne shell plus a number of UNIX commands in a single program, however, it's pretty good. Dave Bursik/..cbosgd!db
heins@orion.UUCP (Michael T. Heins) (09/21/86)
[] >In article <305@esl.UUCP> mac@esl.UUCP (Mike McNamara) writes: >> >> I use "cat | cc -O " myself. > >On what UNIXs does this work? Most cc's that I have seen will not >take stdin. To get the desired results, I have always had to do this: > > ln /dev/tty /dev/tty.c > cc -O /dev/tty.c # damn thing wants a ".c" file! Well, you guys are just wasting CPU time going through that compiler. "adb /dev/mem" is much more manly.
rjk@mrstve.UUCP (Richard Kuhns) (09/21/86)
I'm rather surprised that no one has mentioned the AT&T 3b1 during this
discussion. I realise that there are large differences between the
User Agent on the 3b1 and the Desktop on the Mac, but they look to be
related (disclaimer: I don't have any first-hand experience with the Mac).
Currently, it's possible to set up any single command on the 3b1 with the
User Agent & it's support of windows, using shform(1) if you want to do it
via a shell script, or menu(3t) & message(3t) if you want to handle it
via C code. Using shform(1), for example, it's easy to set up a form
which requests all the info needed to run a grep (filename[s], pattern,
any additional options), which a shell script simply gives to grep.
In general, then, all you'd need is a program ala shform, which reads a
file containing a description of the desired user interface, interacts
with the user using the appropriate graphics interface, and returns the
results of said interactions in a form which a shell script can handle.
Any 3b1 gurus/developers care to comment?
Further disclaimer: I have no relationship with AT&T other than being a
reasonably satisfied user of some of their computers, and no relationship
with Apple at all.
--
Rich Kuhns {ihnp4, decvax, etc...}!pur-ee!pur-phy!mrstve!rjktim@hoptoad.uucp (Tim Maroney) (09/22/86)
I'd like to thank all the people who've replied on this issue so far. I
hope to have time to deal with all the major points soon, but for now, I
just want to make a few comments.
First, I mentioned pseudo-ttys as a necessity in the original article; this
means that a psuedo-tty could easily be bound to a window interface for
those situations in which a command language interface is preferable.
Second, process interconnection with pipes fairly readily into an iconic
shell interface. There would be a "pipe" icon on the desktop. Clicking on
this would create a pipe-shaped icon; selecting application icons would then
link them together into a piped process sequence. Finishing the select
would probably be best accomplished by clicking again on the pipe. Yes, it's
modal, but modality is not an absolute vice.
Third, I suggested that an "interface description language" (obviously not
IDL, the compiler language) could be implemented within the shell, and that
each application could have a formally-described graphic interface in this
way without having to run extra filter processes or modify the applications'
code. Apparently this was not as clear as could be hoped.
Fourth, I think command-language fans are overlooking one of the chief
advantages of graphic interfaces, the impossibility of typing errors.
Again, many thanks!
--
Tim Maroney, Electronic Village Idiot and Self-Assigner of Pretentious Titles
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)
Engineers gleefully note the inability of artists to solve technical
problems, but angrily deny the atrophy of their own aesthetic sense.jdb@mordor.ARPA (John Bruner) (09/23/86)
I seem to have started something that I had really hoped to avoid. I'm probably only making things worse by submitting this, but since the net seems to be a medium devoid of restraint.... I am very dismayed at the general direction that this discussion has taken -- whether or not "vi" is a good editor. The line from my posting which set off all of this discussion was: > I am far more productive with "vi" on UNIX than with any of > the mouse-based editors I've run across on the Mac. This statement is true -- *I* like "vi" and *I* edit *very rapidly* with it. It does *not* say "Everyone would be far more productive with 'vi'", nor does it even say "Everyone would be far more productive with a keyboard-oriented editor". I mentioned "vi" because it is the screen editor that *I* use. It was a concrete example which I cited only to expand upon my general statement: *some* people prefer a keyboard interface (for some tasks) to a mouse-based interface. I cited other examples which noone seems to disagree with -- why didn't someone ridicule me for preferring a command interface with history and aliases to a mouse-based interface? Perhaps this lack of response resulted from my failure to mention specific programs which provoke strong emotional responses in some people, although noone took me to task for my preference for "dbx" over "dbxtool". My sole objective in the paragraph containing the "vi" reference was to state my belief, based upon my own personal experience, that *some* users prefer a keyboard interface for *some* tasks to a mouse-based interface (or worse yet, a hybrid interface that makes one waste lots of time moving one's hands between the keyboard and the mouse). I realize now that I should have said "I am far more productive with my *keyboard-based editor* on UNIX". Of course, then there probably would have been flames about "vi", every flavor of EMACS, the Rand Editor, "ed", "qed", "ex", and who knows what else. A mouse-based interface is appropriate for many situations and users. I claimed that a keyboard-based alternative is appropriate for some. That is all I said. (I find some support for my opinion in the existence of command-key equivalents on the Mac and their popularity among so-called "power users.") I am *not* knocking Apple's user interface guidelines. I am *not* suggesting that the *only* interface be a keyboard-only one. I am *only* suggesting that (at least for *some* things) *some* users desire such an interface as an *alternative*. Preferences for user interfaces, like preferences for editors, vary, so I naturally don't assume that everyone believes as I do. Unfortunately, too often it seems that advocates of mouse-based interfaces are not equally willing to accept that other people may not agree that a mouse is "the only way." I do have some ideas on the original subject: adapting UNIX programs to a Mac interface (both for transport to the Mac and for the implementation of a Mac-like interface on top of UNIX), but as this posting is getting rather long I'll put that material off until later. -- 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
ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459) (09/23/86)
> To add to the mouse vs vi editors debate, I will tell my story. Ditto. > I have NEVER had ANY experience with vi removing text and doing the > wierd things that the previous posters have stated, even when I was a > beginner with vi. It has ALWAYS been the best editor I have used. The problem here is that people are comparing apples and oranges. Everyone's using an editor called "vi". Some satisfied users are using it on dedicated workstations or local terminals on lightly loaded systems. Some complainers are using it on dial-up lines or heavily loaded systems. When I was in the latter group, I found the cursor keys virtually useless. They send a series of characters, and vi rarely managed to buffer and interpret the sequence correctly. Sure enough, lines disappeared leaving random garbage in their place. I've been in the former group, also (sort of): I've used Z, Manx's vi look-alike on the Mac. It's a 100% different experience. If you like keyboard-only editors, you'll love it. So now will everybody shut up about this?
howard@amdahl.UUCP (Howard C. Simonson) (09/23/86)
In article <1117@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > ...There would be a "pipe" icon on the desktop. Clicking on > this would create a pipe-shaped icon; selecting application icons would then > link them together into a piped process sequence. Finishing the select > would probably be best accomplished by clicking again on the pipe. Yes, it's > modal, but modality is not an absolute vice. It doesn't necessarily have to be modal. How about a pipe icon on the desktop into which you drag icons. When icons are dragged into the pipe they become small icons, still visible. As more icons are dragged into the pipe the pipe may expand to accommodate them. When the pipe is constructed to your specifications, a simple double click on the completed pipe would start the commands in motion. The concept of seeing the icons in the pipe is visually pleasing and allows later enhancements to drag icons back out of the pipe and rearrange them after they have been dragged into the pipe. If you desire more pipe icons on the desktop (background pipes?), a menu command that acts like "New Folder" could be used to create a new pipe "device" on the desktop; or it could be a finder param in the LAYO resource, number of pipes on desktop. The non-modal part is the ability to construct and remember partial pipe constructions over other events and program executions. (Requires some temp space on the part of the finder ) Comments? -- I have no technical challenges, Howard C. Simonson just political ones. ...{dragon,hplabs,ihnp4,nsc}!amdahl!howard [ Opinion? What opinion!? I think you have the wrong guy... ]
edusoft@utecfa.UUCP (Educational Software) (09/23/86)
Larry Tesler writes in article 164@apple.UUCP > In article <267@uwmacc.UUCP> dubois@uwmacc.UUCP (Paul DuBois) writes: > >Mac users (some of 'em, anyway) like to talk about modeless > >operation, but let's not forget: the mouse *IS* a mode. > >Modelessness is a myth, propagated sometimes by people who should > >know better. > If I can figure out how to use vi, I'll reply. I agree that modelessness > is a technically vague term. It could be argued that even a text editor > like MacWrite has one mode, "obey-next-input mode". But if a program has > one mode, it has no mode changes, and thus we call it modeless. It is > also arguable that a font change command produces a mode, but so does a > caps lock key; I call either a "shift", which, as modes go, is innocuous > because the effect of forgetting which mode you are in is certainly less > drastic than that of typing "23d Street" without first entering insert > mode in vi. > > Depending on how you choose to define "mode", the mouse could be called a > mode, but then so could the "7" key on a typewriter. A useful definition > of mode is a state of a user interface that affects the interpretation of > subsequent inputs without obvious indication. It is possible on the Macintosh, > using clover keys, to bring up a dialog box and thus enter a mode unknowingly. > But it is exceedingly rare compared with systems like vi that overload the > typing keys with functional meanings. > > Let me add that, although I agree vi is an obnoxious editor, I do think it > deals with the mode problem gracefully. Bad keystrokes often beep, undo is > always available for one command, and most vowels enter insert mode so it is > difficult to type a word as a command. > > Modelessness is not a myth. Like "seamlessness" or "painlessness", it is an > ideal that may rarely be attainable but is always worth approximating. The > alternative is surely inhumane computing. I don't really know whether modelessness is a myth or not, (though I suspect it is a myth). For example, the dialog boxes and file selection boxes and pull-down menus and click-drag mouse functions are ALL modes. The idea is, however, to keep the modes simple and small, so that a user's options and how to get at them are obvious. So, MacWrite has lots of little modes, and vi has two big modes. ----- bill idsardi educational software products .... utzoo!utcsri!utecfa!edusoft
edm@tikal.UUCP (Ed Morin) (09/24/86)
> What's the difference between a duck?
One of his legs are both the same! :-)
Ed Morin
Computer Resource Engineer
Teltone, Inc.
...uw-beaver!tikal[!colossus]!edmadam@mtund.UUCP (Adam V. Reed) (09/24/86)
Larry Tesler: > .... A useful definition > of mode is a state of a user interface that affects the interpretation of > subsequent inputs without obvious indication. It is possible on the Macintosh, > using clover keys, to bring up a dialog box and thus enter a mode unknowingly. > But it is exceedingly rare compared with systems like vi that overload the > typing keys with functional meanings. Although I enjoy the relative orthogonality of vi, I think that some visible indication of whether one's input will be interpreted as text or commands might be very desirable. But would it really be enough to make vi "modeless"? Adam Reed (mtund!adam)
stephenw@murdu.OZ (Stephen Withers) (09/25/86)
In article <1897@utecfa.UUCP> edusoft@utecfa.UUCP (BIll Idsardi) writes: >The idea is, however, to keep the modes simple and small, so that >a user's options and how to get at them are obvious. > >So, MacWrite has lots of little modes, and vi has two big modes. I think the question is more to do with the "depth" of a mode, rather than its complexity. With MacWrite, "insert mode" is so shallow that you can't call it a mode - you can hit any of the shortcut keys as you type. With vi, you must get out of exit mode before you can do anything but type more characters. Anyway, I believe that one of the main determinants of a good user interface is how easy it is to do something catastrophic. With MacWrite (and most Mac programs) it's hard; with vi (and most Unix programs?) it's easy.
magik@chinet.UUCP (Ben Liberman) (09/25/86)
In article <15530@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes: > >A mouse-based interface is appropriate for many situations and users. >I claimed that a keyboard-based alternative is appropriate for some. >That is all I said. (I find some support for my opinion in the >existence of command-key equivalents on the Mac and their popularity >among so-called "power users.") > I agree with you totally. To support either one to the exclusion of the other is a waste of time (at many levels:-). One of the joys of the mac user interface is it allows the novice and expert to begin to operate effectively with no previous experience. As you learn some of the shortcuts you get to do the same things FASTER (having a larger and less obvious command vocabulary). At the novice level you can get around slower with your much limited vocabulary, but you CAN get around. I've run in to some who seem to believe that there is something WRONG with command-key enhancement of the commonly percieved "mac interface". ---------------------- Ben Liberman ihnp4!homebru!magik "Whatever it was that I said...uh...I didn't mean it....honest !!!)
cy@killer.UUCP (Cyrus Foughty) (09/25/86)
In article <981@cit-vax.Caltech.Edu>, wetter@tybalt.caltech.edu.Caltech.Edu (Pierce T. Wetter) writes: > In article <15372@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes: > > I am far more productive with "vi" on UNIX than with any of > >the mouse-based editors I've run across on the Mac. [ deleted crap ( wasted space) ] > with the mouse isn't faster then banging away on random cursor keys. It's true > that you can go directly to a specific line number but you can't easily go up > five lines and over twenty characters. Also a mouse based editor is much easier Alright, try this : when in vi in the command mode enter: 5k20l See how fast that is! Your probably just to lazy to learn vi, it is inifinitely flexible compared to any other editor. One must invest the time to learn!!! I'll race you any day, and I'm not a touch typist. (boy will those people be in trouble when Dvorak takes over, and it will) > to cut & paste in (which if you looked at code I've written you'll know why > I like this--" Who needs a for next loop I'll just paste it in five times") > > Also, you need to move your hands away from the "home row" whenever you > hit the escape key or any other "control key". The mouse isn't any worse > ( unless you have an infinate typing speed). However, there is one small > thing I should mention, I'm using a trackball instead of a mouse (desk space > Yay!!!!!!!). If you are using a mouse on a towel (yucky surface) I might > believe you but otherwise. Snicker Snicker... > > Nuff Said > > Pierce wetter The above are the rantings of an deranged group of folks. not really ;-) cy {dj3b1,ihnp4}!killer!cy "Degree,degree..... I don't need no stinking degree!!!" Dangermouse is alive!!
wcs@ho95e.UUCP (#Bill_Stewart) (09/26/86)
In article <791@mtund.UUCP> adam@mtund.UUCP (Adam V. Reed) writes: >Larry Tesler: >> .... A useful definition >> of mode is a state of a user interface that affects the interpretation of >> subsequent inputs without obvious indication........ >> But it is exceedingly rare compared with systems like vi that overload the >> typing keys with functional meanings. >Although I enjoy the relative orthogonality of vi, I think that some >visible indication of whether one's input will be interpreted as text >or commands might be very desirable. But would it really be enough to >make vi "modeless"? AT&T Version 3.9 of vi (comes with SVR2) has a "showmode" option which does just that. It's part of our standard options for novices. I don't use it, partly because of the wonderful things it does on paper terminals :-. It helps a bit when you forget which mode you're in. Put "set showmode" in your $EXINIT. Most emacs versions I've used have similar features, at least to the extent of moving the cursor to line 24 during a ^X: command; when I use emacs I keep it in Electric-C-Mode or nroff-mode (just to add fuel to the is-emacs-modeless fire.) My reasons for using vi are more plebian; I learned it first and for most of my work emacs isn't a big enough gain to switch. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
das@well.UUCP (David Shayer) (09/27/86)
After listening to the Unix-Mac portability debate, I have another thought about Mac compatibility with Unix. Sure the Mac ought to run C programs from Unix environments. But what about running Unix shell scripts? I have been using MPW (Mac Programmers Workshop) lately, and it has a Unix-like command language, but it has many frustrating minor differences. Obviously (to me anyway) we don't want to just run Unix shell scripts at the Finder level. After all, the whole idea of the Mac is to get away from the user having to do that kind of stuff. Unix may be very powerful, and we all like it (or at least use it), but a lot of people bought Macs specifically so they don't have to put up with commands like grep -v foo > bar. But at the programmers level, it is certainly useful to have Unix-like capabilities. MPW does provide most of the same types of commands as Unix, if you've been waiting for a Unix-like development environment on the Mac, check out MPW. However, most of the commands have different names and different formats. Since most of the same commands and utilities exist, it would be nice if they had the same name. MPW is too Unix-like for Apple not to have realized they were mostly duplicating Unix. But it would be nice if they had gone all the way, so you could download a shell archive and compile it directly on your Mac, or download a Unix program and its makefile and make it in one step. Instead, MPW has a lot of little changes. For instance, the wildcard characters are not ? and *, but ? and command-x. Make files use command-f instead of : to note dependencies. The whole command language is full of specialized Mac-keyboard-only characters. I have a proposal. A program (in C, or a Unix or MPW shell script) to convert Unix shell scripts to MPW shell scripts and vice versa, informing you of commands that cannot be converted (there are few). I must admit that I don't know Unix shell language well enough (or MPW shell language either, its pretty complicated). But if I inspire somebody, please post a copy. ----------------------- David Shayer @ The Well well!das "Most of the time, for most programmers, what a compiler produces is not object code but error messages."
mob@mit-amt.MIT.EDU (Mario O. Bourgoin) (09/28/86)
> Your probably just to lazy to learn vi, it is inifinitely > flexible compared to any other editor. Allright, try this for a change: make vi behave like Emacs, my favorite editor. We already know that Emacs can behave like vi pretty easily. Show that it goes the other way: that should be a good test of flexibility. The persons whom I know use vi look terribly clumsy when using it. All those keystrokes! All that careful thought about "How am I going to do this?" And they've used it for more than six years!! And the work that they do to get effects that are easy to do in Emacs!!! Show me that vi "is infinitely flexible compared to" Emacs. --Mario P.S. After your comment about wasted space, why did you include the rest of the other person's article in yours?
tdn@spice.cs.cmu.edu (Thomas Newton) (09/28/86)
>> It's true that you can go directly to a specific line number but you can't >> easily go up five lines and over twenty characters. I don't know about vi, but there are several ways it could be done in EMACS. And in Hemlock, an EMACS-family editor built into Spice Lisp, one can point and click using the puck or type keyboard commands as one prefers. > Your probably just to lazy to learn vi, it is infinitely > flexible compared to any other editor. Compared to Gosling EMACS or GNU EMACS? Programmability is a big win... >> to cut & paste in (which if you looked at code I've written you'll know why >> I like this--" Who needs a for next loop I'll just paste it in five times") The Kill buffer in EMACS is analogous to the Macintosh clipboard in that text that is placed into it may be yanked ("pasted") several times. Some versions of EMACS even have kill rings (translation: multiple Clipboards). -- Thomas Newton
levy@ttrdc.UUCP (Daniel R. Levy) (09/30/86)
In article <791@mtund.UUCP>, adam@mtund.UUCP (Adam V. Reed) writes: >Larry Tesler: >> .... A useful definition >> of mode is a state of a user interface that affects the interpretation of >> subsequent inputs without obvious indication. It is possible on the Macintosh, >> using clover keys, to bring up a dialog box and thus enter a mode unknowingly. >> But it is exceedingly rare compared with systems like vi that overload the >> typing keys with functional meanings. >Although I enjoy the relative orthogonality of vi, I think that some >visible indication of whether one's input will be interpreted as text >or commands might be very desirable. But would it really be enough to >make vi "modeless"? > Adam Reed (mtund!adam) :set showmode ('INPUT MODE' will show up on the status line when appropriate [if you have also :set terse then there is just an 'I']) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy