Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!JASPER.PALLADIAN.COM!jeff From: jeff@JASPER.PALLADIAN.COM.UUCP Newsgroups: comp.sys.apollo Subject: Re: Downside and Upside Message-ID: <870612024910.4.JEFF@CHUGACH.PALLADIAN.COM> Date: Fri, 12-Jun-87 02:49:00 EDT Article-I.D.: CHUGACH.870612024910.4.JEFF Posted: Fri Jun 12 02:49:00 1987 Date-Received: Sat, 13-Jun-87 20:47:49 EDT References: <8706111647.AA02770@hi-csc.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Jeff Gibbons Distribution: world Organization: The ARPA Internet Lines: 97 Date: Thu, 11 Jun 87 11:47:53 cdt From: Brett Slocum Dan Freedman writes: > The area in which the cursor must be in order for you to type is > far too small. . . . This is a fundamental flaw due to the > same cursor being used for both pointing and text insertion. First, I have never had trouble hitting the 'next window' key to get to the input window. I don't mind making one keystroke every now and then. I never hear complaints about this either. Second, I am not aware of any workstation that uses two cursors. How would you control them? One cursor for the mouse, and one for the arrow keys? And which one do you use for text input?? Two cursors seems absurd to me. I find Apollo's use of the cursor THE SINGLE MOST BRAIN-DAMAGED aspect of their machines. Dan Freedman is correct in saying that they confound mouse input and keyboard input by using a single cursor. I spend a great deal of time in front of either a Symbolics Lisp Machine or a DN3000. The LispM uses the "two cursor" approach in the following way. There is one cursor for the mouse (generally an arrow) for pointing and clicking. There is also one for keyboard input (generally a blinking solid rectangle). Every window for which keyboard input is relevant maintains its own current keyboard input position. At any given time, one window is considered "selected" and if this window takes keyboard input then the keyboard cursor is shown at its keyboard input position. Selecting a different window will move the keyboard cursor from the old window to the new window at its keyboard input position (if there is one; otherwise there is no keyboard cursor while said window is selected). Time and space do not permit me to relate all of the virtues of this methodology but I will give a few examples. First, one can easily change activities by selecting different windows either via a special key sequence or putting the mouse cursor in the desired window and clicking a mouse button. When you return to a window, you are right where you left it without having to put the keyboard cursor where it used to be; it's already there. In the ZMACS editor on the LispM (the descendant of EMACS that incorporates most if not all of the wish list recently posted and more) the keyboard cursor can be moved either by keystrokes (control and other shifted characters) or pointing with the mouse and clicking (this is the requisite component; moving the mouse and clicking to move the text cursor, not just moving the mouse). Cut, copy, and paste? With the mouse I can easily sweep out any random amount of text between a down click and an up click. A keystroke copies it, a different keystroke cuts it. Both operations put the cut or copied text on a ring that I can cycle through. Other keystrokes paste the current top of the ring at the current keyboard input cursor. There are more sophisticated uses of the mouse where a single sweep as described above will copy and paste into the current keyboard position in the single action. In ZMACS buffers with syntax modes, single clicks can select structured objects for cut, copy or paste. For example, in Lisp Mode, clicking on a parenthesis selects the form bounded by the matching parenthesis. Strings and symbols can similarly be selected. I so prefer the LispM interface style that I have used the following method to port lisp code to the DN3000. I open a network virtual terminal to my DN3000 using SUPDUP from my LispM. I run EMACS on the DN3000 through this connection so the interaction is on my LispM screen and keyboard. I run LISP on the DN3000 in a shell buffer of the EMACS as well as a CSH in another buffer. We extended the SUPDUP and EMACS to take mouse clicks on the LispM screen and use them to position the EMACS cursor. I switch to ZMACS to do my source editing because it is much more powerful than EMACS and can transparently write the output to our Apollo file server. In fact, the application I have been porting is a highly graphic interactive expert system. I can write, debug and run the application on the DN3000 from my LispM while the application itself uses the DN3000 screen, keyboard and mouse. Anyone who has ever tried to debug complicated keyboard and mouse I/O will recognize the beauty of having the debug interactions separated from the application interactions this way (it's almost like beating the Heisenberg Principle). In porting the application, I wanted to duplicate precisely the user interface we developed for it on the LispM. The biggest single difficulty was the cursor. The application uses only one large Apollo window (approx. 1024x768) and when the mouse is in this window, I want the cursor to be a certain shape (usually an arrow but sometimes an hour glass or cross hairs). But if you enable the cursor so the DN3000 will track the mouse motion and update the cursor, the machine enforces the fact that when in motion the shape shall be an arrow and no other, and when stationary the shape shall blink like it or not. This is rediculous. My only option was to disable the cursor and update my own shape in response to mouse move events. First, it shouldn't be this painful. And second, paging can cause disasterous performance here when my process has been paged out and the mouse reenters my window. No, I don't think Apollo has the right ideas for the cursor. And in my opinion there is an existence proof that workstations exist using the "two cursor" methodology where it is anything but absurd. Quite the contrary. You are invited to come into the future with the rest of us. Flame off. jeff