Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbdkc1!gwe
From: g...@cbdkc1.UUCP ( George Erhart x4021 CB 3E373 DEBR )
Newsgroups: net.micro.mac
Subject: Porting UNIX Applications to the Mac
Message-ID: <1572@cbdkc1.UUCP>
Date: Fri, 12-Sep-86 07:56:57 EDT
Article-I.D.: cbdkc1.1572
Posted: Fri Sep 12 07:56:57 1986
Date-Received: Sat, 13-Sep-86 05:03:42 EDT
Reply-To: g...@cbdkc1.UUCP ( George Erhart x4021 CB 3E373 DEBR )
Organization: AT&T Bell Laboratories, Columbus
Lines: 18
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!gwe
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!hoptoad!tim
From: t...@hoptoad.uucp (Tim Maroney)
Newsgroups: net.micro.mac,net.unix
Subject: Re: Porting UNIX Applications to the Mac
Message-ID: <1091@hoptoad.uucp>
Date: Mon, 15-Sep-86 05:09:35 EDT
Article-I.D.: hoptoad.1091
Posted: Mon Sep 15 05:09:35 1986
Date-Received: Mon, 15-Sep-86 18:36:01 EDT
References: <1572@cbdkc1.UUCP>
Reply-To: t...@hoptoad.UUCP (Tim Maroney)
Organization: Centram Systems, Berkeley
Lines: 70
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"
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!caip!sri-spam!mordor!jdb
From: j...@mordor.ARPA (John Bruner)
Newsgroups: net.micro.mac,net.unix
Subject: Re: Porting UNIX Applications to the Mac
Message-ID: <15372@mordor.ARPA>
Date: Mon, 15-Sep-86 12:55:11 EDT
Article-I.D.: mordor.15372
Posted: Mon Sep 15 12:55:11 1986
Date-Received: Mon, 15-Sep-86 20:59:24 EDT
References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp>
Reply-To: j...@mordor.UUCP (John Bruner)
Organization: S-1 Project, LLNL
Lines: 70
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 [j...@s1-c.ARPA] (415) 422-0758
UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!cit-vax!tybalt.caltech.edu!wetter
From: wet...@tybalt.caltech.edu.Caltech.Edu (Pierce T. Wetter)
Newsgroups: net.micro.mac,net.unix
Subject: Re: Porting UNIX Applications to the Mac
Message-ID: <981@cit-vax.Caltech.Edu>
Date: Mon, 15-Sep-86 18:40:35 EDT
Article-I.D.: cit-vax.981
Posted: Mon Sep 15 18:40:35 1986
Date-Received: Mon, 15-Sep-86 22:12:14 EDT
References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp> <15372@mordor.ARPA>
Sender: n...@cit-vax.Caltech.Edu
Reply-To: wet...@tybalt.caltech.edu.UUCP (Pierce T. Wetter)
Organization: Calfornia Institute of Technology
Lines: 29
In article <15...@mordor.ARPA> j...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!jade!eris!mwm
From: m...@eris.berkeley.edu (Mike Meyer)
Newsgroups: net.micro.mac,net.unix
Subject: Re: Porting UNIX Applications to the Mac
Message-ID: <1279@jade.BERKELEY.EDU>
Date: Tue, 16-Sep-86 18:09:45 EDT
Article-I.D.: jade.1279
Posted: Tue Sep 16 18:09:45 1986
Date-Received: Wed, 17-Sep-86 12:25:46 EDT
References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp> <15372@mordor.ARPA>
<981@cit-vax.Caltech.Edu>
Sender: use...@jade.BERKELEY.EDU
Reply-To: m...@eris.UUCP (Mike Meyer)
Organization: Missionaria Phonibalonica
Lines: 46
In article <9...@cit-vax.Caltech.Edu> wet...@tybalt.caltech.edu.UUCP
(Pierce T. Wetter) writes:
>In article <15...@mordor.ARPA> j...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dil...@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.mac
Subject: Re: Porting UNIX Applications to the Mac
Message-ID: <8609170521.AA18527@cory.Berkeley.EDU>
Date: Wed, 17-Sep-86 01:21:17 EDT
Article-I.D.: cory.8609170521.AA18527
Posted: Wed Sep 17 01:21:17 1986
Date-Received: Wed, 17-Sep-86 06:28:09 EDT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 14
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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!voder!apple!tesler
From: tes...@apple.UUCP (Larry Tesler)
Newsgroups: net.micro.mac,net.unix
Subject: Re: Porting UNIX Applications to the Mac
Message-ID: <164@apple.UUCP>
Date: Fri, 19-Sep-86 01:16:53 EDT
Article-I.D.: apple.164
Posted: Fri Sep 19 01:16:53 1986
Date-Received: Mon, 22-Sep-86 21:14:33 EDT
References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp> <15372@mordor.ARPA>
<981@cit-vax.Caltech.Edu> <1257@utastro.UUCP> <267@uwmacc.UUCP>
Reply-To: tes...@apple.UUCP (Larry Tesler)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 37
In article <2...@uwmacc.UUCP> dub...@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.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site utecfa.UUCP
Path: utzoo!utcsri!utai!utecfa!edusoft
From: edus...@utecfa.UUCP (Educational Software)
Newsgroups: net.micro.mac,net.unix
Subject: Re: Porting UNIX Applications to the Mac
Message-ID: <1897@utecfa.UUCP>
Date: Tue, 23-Sep-86 12:52:41 EDT
Article-I.D.: utecfa.1897
Posted: Tue Sep 23 12:52:41 1986
Date-Received: Tue, 23-Sep-86 14:43:46 EDT
References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp>
Organization: Engineering Computing Facility, University of Toronto
Lines: 52
Larry Tesler writes in article 1...@apple.UUCP
> In article <2...@uwmacc.UUCP> dub...@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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!voder!apple!lsr
From: l...@apple.UUCP (Larry Rosenstein)
Newsgroups: net.micro.mac
Subject: Editor Interfaces
Message-ID: <179@apple.UUCP>
Date: Tue, 23-Sep-86 20:05:42 EDT
Article-I.D.: apple.179
Posted: Tue Sep 23 20:05:42 1986
Date-Received: Wed, 24-Sep-86 02:58:39 EDT
References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp> <15372@mordor.ARPA>
<981@cit-vax.Caltech.Edu> <1279@jade.BERKELEY.EDU>
Reply-To: l...@apple.UUCP (Larry Rosenstein)
Organization: Advanced Development Group, Apple Computer
Lines: 33
In article <1...@jade.BERKELEY.EDU> m...@eris.UUCP (Mike Meyer) writes:
>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.
>
There was a paper entitled "The Evaluation of Text Editors: Methodology and
Empirical Results" by Teresa L. Roberts and Thomas P. Moran in the April
1983 Communications of the ACM.
This study compared 9 different editors (including Emacs, Teco, and several
Xerox mouse-based editors) using predicted and actual times to perform a
variety of tasks. There were a couple of interesting things in the paper.
First, in their predicted times, they concluded that "the homing time
between the keyboard and pointing device is not a major problem". The
exception to this was the WANG editor that relies heavily on function keys
separate from the main typing array.
Second, in the actual timings with expert users the 2 fastest editors were
mouse-based, the third was the WANG.
--
Larry Rosenstein
Object Specialist
Apple Computer
AppleLink: Rosenstein1
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: l...@Apple.CSNET
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!hplabs!tektronix!teklds!zeus!bobr
From: b...@zeus.UUCP (Robert Reed)
Newsgroups: net.micro.mac,net.unix
Subject: Re: Modelessness (Was porting UNIX applications to the mac)
Message-ID: <585@zeus.UUCP>
Date: Wed, 24-Sep-86 15:19:39 EDT
Article-I.D.: zeus.585
Posted: Wed Sep 24 15:19:39 1986
Date-Received: Fri, 26-Sep-86 01:00:22 EDT
References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp> <1897@utecfa.UUCP>
Reply-To: b...@zeus.UUCP (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Lines: 51
Bill Idsardi writes in article 1...@utecfa.UUCP
>
> 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.
Proving the myth of modelessness by picking at nits seems to be a waste of
time. Larry Tesler gave a reasonable definition of the "modes" of which
people speak when they talk about modeless programming:
A useful definition of mode is a state of a user interface that affects
the interpretation of subsequent inputs without obvious indication.
The operant words here are "WITHOUT OBVIOUS INDICATION." We can argue all
month about whether holding down the shift key or pushing the mouse button
while looking at a pull-down menu constitutes a mode in the strictest
definition, but all of this would be beside the point. The idea behind
modeless programming is to eliminate surprises.
If I click-drag an object or pull down a menu, or hold down the shift key,
it is a conscious act for which I am getting direct feedback from the
system. As a novice user of vi, I was constantly surprised by trying to
enter text, only to find that I was in command mode (with no obvious
indication). That is the point.
One additional attribute of systems which are objectionably modal is their
way of navigating through the modes. If holding the shift key is considered
a mode, it is not very objectionable because I can get out of it by just
letting go. The same goes for pulldown menus. If I don't like the choices,
I can intuitively avoid them by moving the cursor away before letting go.
Getting out of insert mode in vi, is not quite as easy, but can be easily
acquired through the learned behavior of hitting the ESC key.
The lesson here is NOT that systems should have no global states (i.e.,
modes) but that:
o Users should be able to know, without having to query, those states
of the system that will affect what they are about to do.
o If in a state that the user no longer desires, they should be able to
correctly guess how to get out of it (e.g., letting go of the shift
key).
Robert Reed, Tektronix CAE Systems Division, b...@zeus.TEK
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!mark
From: m...@cbosgd.ATT.COM (Mark Horton)
Newsgroups: net.micro.mac,net.unix
Subject: Re: Modelessness (Was porting UNIX applications to the mac)
Message-ID: <2637@cbosgd.ATT.COM>
Date: Mon, 29-Sep-86 16:19:04 EDT
Article-I.D.: cbosgd.2637
Posted: Mon Sep 29 16:19:04 1986
Date-Received: Tue, 30-Sep-86 20:58:02 EDT
References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp> <1897@utecfa.UUCP> <585@zeus.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 58
In article <5...@zeus.UUCP> b...@zeus.UUCP (Robert Reed) writes:
> A useful definition of mode is a state of a user interface that affects
> the interpretation of subsequent inputs without obvious indication.
>
>The operant words here are "WITHOUT OBVIOUS INDICATION." We can argue all
>month about whether holding down the shift key or pushing the mouse button
>while looking at a pull-down menu constitutes a mode in the strictest
>definition, but all of this would be beside the point. The idea behind
>modeless programming is to eliminate surprises.
>
>If I click-drag an object or pull down a menu, or hold down the shift key,
>it is a conscious act for which I am getting direct feedback from the
>system. As a novice user of vi, I was constantly surprised by trying to
>enter text, only to find that I was in command mode (with no obvious
>indication). That is the point.
Sorry, Bob, I disagree. Your version of vi (3.7) doesn't show you when
you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI
clone. (It says "INPUT MODE" right there on the bottom line, or "I"
if you have terse set. There are similar messages for r and R modes.)
In System V release 2, you can get this by putting "set showmode"
in your EXINIT, in release 3 it's on by default.
In spite of this, I still consider vi a moded editor, and I think most
others do too. As an extreme example, ex command mode is certainly a
mode, with a very obvious visual indication (the : prompt and cursor
at the bottom of the screen.)
There's nothing wrong with being moded, it's just a personal preference.
I've taught vi to many novices, such as secretaries; I stick to a 10
command subset and they seem quite happy.
Mice and other pointing devices are handy for lots of things, but with
only two hands, you can't keep one hand on the mouse all the time. A
really good mouse interface never has your hands on the keyboard, you
do everything with the mouse. (MacPaint is a good example of this.)
But for a text editor, you can't reasonably input new text with a mouse,
and there's the problem. There are so many things you want to do in a
complex text editor that you can't really put them all on a menu without
having zillions of menus and never being able to find anything. This
goes for shell commands too.
A person who has learned a keyboard oriented editor like vi or emacs
becomes very familiar with that editor. Commands become reflexive
habits, and switching to another editor is very painful; this is why
there are so many flames about editors. I personally have the vi
command set hardwired in my fingers, so I'm not anxious to learn another
text editor or word processor. It took a quantum leap in editor quality
to get people to switch from line editors to screen editors, and there
are still plenty of line editor users out there. (My office mate hunts
and pecks at ed.) It will take a similar quantum leap, plus near
universality of mice as standard input devices, plus a mousecap or
similar notion, to make people jump from screen editors to mouse editors.
So far I haven't seen the quantum leap, at best things seem about even.
(Cursor motion is easier but commands like "delete 2 sentences" or
"find the matching parenthesis", or even a simple search, are harder.)
Mark Horton
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!mit-amt!mit-eddie!barmar
From: bar...@mit-eddie.MIT.EDU (Barry Margolin)
Newsgroups: net.micro.mac,net.unix
Subject: Re: Modelessness (Was porting UNIX applications to the mac)
Message-ID: <3360@mit-eddie.MIT.EDU>
Date: Wed, 1-Oct-86 22:56:37 EDT
Article-I.D.: mit-eddi.3360
Posted: Wed Oct 1 22:56:37 1986
Date-Received: Sat, 4-Oct-86 01:33:20 EDT
References: <1572@cbdkc1.UUCP> <1091@hoptoad.uucp> <1897@utecfa.UUCP>
<585@zeus.UUCP> <2637@cbosgd.ATT.COM>
Reply-To: bar...@mit-eddie.UUCP (Barry Margolin)
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
Lines: 44
In article <2...@cbosgd.ATT.COM> m...@cbosgd.ATT.COM (Mark Horton) writes:
>In article <5...@zeus.UUCP> b...@zeus.UUCP (Robert Reed) writes:
>> A useful definition of mode is a state of a user interface that affects
>> the interpretation of subsequent inputs without obvious indication.
>>
>>The operant words here are "WITHOUT OBVIOUS INDICATION."
...
>>As a novice user of vi, I was constantly surprised by trying to
>>enter text, only to find that I was in command mode (with no obvious
>>indication). That is the point.
>
>Sorry, Bob, I disagree. Your version of vi (3.7) doesn't show you when
>you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI
>clone. (It says "INPUT MODE" right there on the bottom line, or "I"
>if you have terse set. There are similar messages for r and R modes.)
...
>In spite of this, I still consider vi a moded editor, and I think most
>others do too. As an extreme example, ex command mode is certainly a
>mode, with a very obvious visual indication (the : prompt and cursor
>at the bottom of the screen.)
>
>There's nothing wrong with being moded,
I think that we need to decide how "obvious" the indications must be
before one is willing to call something "modeless". I don't consider a
word or two somewhere else on the screen, or a change in shape of the
cursor (as is common in many PC applications) obvious enough. However,
moving the cursor out of the window, as is done for Emacs ESC-X commands
or Macintosh dialogs, is about as obvious as you can get without
grabbing the user by the collar and screaming "What extended command do
you want?" in his ear.
Emacs and MacWrite, however, are only modeless to a slightly greater
extent than vi. Emacs has major (C, Lisp, Fundamental) and minor (Auto
Fill, Overwrite, Macro Learn) modes. MacWrite has modes that specify
the justification, font, and style of the text to be typed in. I think
that the difference between these and vi is the extent to which use of
the editor depends on the modes; a novice Emacs user might hardly ever
change modes, but a vi can't be used without going between insert,
overwrite, and edit modes relatively frequently.
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmar