slocum@hi-csc.UUCP (Brett Slocum) (06/11/87)
Dan Freedman writes: > ... with "rm", you can remove a sysboot file, but with "dlf" you > can't. First of all, you can delete a sysboot fil with 'dlf', you just need to change the type of the sysboot file from 'boot' to 'uasc' using 'obty'. The reason that 'rm' will delete it is that Un*x doesn't understand file types, and doesn't care that a file of type 'boot' should not be deleted, unless the user REALLY wants to. This is a good thing because I would be mighty upset if the sysboot file on my Winchester got erased, and my system was dead until I could INVOL the disk again. If the sysboot file is missing from a Winchester, all reboots will fail. > 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. > You can just barely use the system as a user without knowing > Aegis (until your processes need blasting) 'kill' works just fine for killing processes, and 'kill -9' has taken care of the same things that 'sigp -blast' has, in my experience. We have many users here who know nothing about Aegis who get along fine without it. > ... ALL the keys ... self-repeating I would probably spend half my time erasing extra characters, if they were all auto-repeat. That's what the 'repeat' key is for. > Serial ports do not seem to be accessable from any node except > the ones that they are connected to. Remote processes can access sio lines. > tabs You can redefine the tab key to be a real tab. See earlier message. > DSEE ... certain "simple" things difficult (like moving a library > from one system to another). I've moved many libraries between systems, use 'cpt'. I have separate directories that contains one system and associate library directories. I just used 'cpt' to copy the library from one place to another. When someone sets that library as current, the system directory is updated. I have yet to see a system that transparently integrates as many drastically different machines as Aegis does. Everything from ancient dn400s to Alliant's concurrent processor. Look at the bizzareness Sun goes through to handle 68000s and 68020s.
jeff@JASPER.PALLADIAN.COM.UUCP (06/12/87)
Date: Thu, 11 Jun 87 11:47:53 cdt
From: Brett Slocum <hi-csc!slocum@umn-cs.ARPA>
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.
jeffbobr@zeus.TEK.COM (Robert Reed) (06/12/87)
In article <8706111647.AA02770@hi-csc.uucp> slocum@hi-csc.UUCP (Brett Slocum) writes:
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.
It is not absurd, and in fact works very well. The classic example is from
smalltalk, and is also present on the Macintosh (and I suspect therefore,
also under GEM). There are actually a plethora of cursors, one which is
always attached to the pointing device, and then one each alpha cursor
associated with each window. The presence of the pointing cursor selects
the window to which keyboard input is directed, but the echo occurs at the
position of the alpha cursor. The alpha cursor can be moved around within
any particular window THROUGH AN EXPLICIT SELECTION EVENT. For example, a
simple selection (could be a DM command bound by default to, say, the left
button) moves the appropriate alpha cursor to the position of the pointing
cursor. In other words, each window remembers more of what the user was
doing last. There are some trades and balances that occur with this change,
but having used both, I find the technique described here produces a much
lower frustration level than the current DM scheme.
I would probably spend half my time erasing extra characters, if they
were all auto-repeat. That's what the 'repeat' key is for.
Oh dear, are there still people around who prefer an explicit repeat key to
momentarily delayed autorepeat? I am currently typing on a keyboard with
this latter scheme. I have no problems with doubled keys because the normal
stroke of hitting a key produces only a single character. However, for any
key that I want to repeat, alphanumeric, control, or otherwise, all I have
to do is hold down the key, and after a brief pause, the key starts
repeating at a manageable rate. I don't have to go through any contortions
to reach the repeat key (which is great since there isn't any :-), and it's
a much better solution. I thought repeat keys had died with the days of the
electromechanical teletype, until I first saw an Apollo keyboard.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKfreedman@calgary.UUCP (06/13/87)
In article <8706111647.AA02770@hi-csc.uucp>, slocum@hi-csc.UUCP (Brett Slocum) writes: > Dan Freedman writes: > > ... with "rm", you can remove a sysboot file, but with "dlf" you > > can't. > > First of all, you can delete a sysboot fil with 'dlf', you just need > to change the type of the sysboot file from 'boot' to 'uasc' using > 'obty'. You may consider this to be a feature, but I don't. At the very least, the force option (dlf -f) should remove any file including sysboots. The documentation makes no mention of how to delete a sysboot file. > > 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. Well, what you are saying is "I don't mind living with the problem now and then". I find it annoying to knock the mouse a fraction of an inch and have to stop my typing in mid-word. This is a problem on other window systems too, but the typable area is much bigger, making inadvertant mouse movements less critical. > > > You can just barely use the system as a user without knowing > > Aegis (until your processes need blasting) > > 'kill' works just fine for killing processes, and 'kill -9' has taken > care of the same things that 'sigp -blast' has, in my experience. Well, in my experience, kill does not get rid of everything, even when used with the -9 option. I'm surprised to hear you say that you have never had a proccess that kill wouldn't kill. There are many times when I have only been able to get rid of a process by sigp -b'ing it. > > ... ALL the keys ... self-repeating > > I would probably spend half my time erasing extra characters, if they > were all auto-repeat. That's what the 'repeat' key is for. Well, what you're saying here is, "just because the default is the way I like it, its ok that others are stuck with something they don't like". I think that what I said in my original posting is that the repeatibility of keys should be at the discretion of the user. If thats not what I said, that's what I meant to say. > > Serial ports do not seem to be accessable from any node except > > the ones that they are connected to. > > Remote processes can access sio lines. > ...But local ones cannot, yet they certainly can look at the directory in which the sio ports reside. They can ls or ld them, copy them, etc., but they can't open them. This is called non-transparency of the filesystem. > > tabs > > You can redefine the tab key to be a real tab. See earlier message. ...but the DM doesn't like tabs, especially ones that are supposed to be of standard (ie every 8 characters) size. > > > DSEE ... certain "simple" things difficult (like moving a library > > from one system to another). > > I've moved many libraries between systems, use 'cpt'. Well, bang goes the data abstraction when you have to do that. And that was only one example. There are some others, and unfortunately they tend to be things that many users around here like to do often. I don't know what your purpose was in posting a followup article like that. You seem to have taken the narrowest possible viewpoint in the flimsiest possible context and found partial solutions to problems that often were not the true subject of my posting. My purpose in posting this followup is to make available a reply to yours for those people not familiar enough with Apollos to be able to judge between our comments. Dan Freedman.
benoni@ssc-vax.UUCP (06/13/87)
In article <8706111647.AA02770@hi-csc.uucp>, slocum@hi-csc.UUCP (Brett Slocum) writes: > 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. > Maybe not two cursors. But a cursor and and pointer per the Sun machines seem much nicer. The idea that you can have the pointer *anywhere* in the window and be able to type is not only intelligent design but functionally superior to Apollo's single command line nonsense where you have to have the cursor/pointer on the bottom line of the window or else face no text entry and beeping. > have many users here who know nothing about Aegis who get along fine > without it. Unfortunately we have very few users that get along with Aegis.
richard@gryphon.UUCP (06/14/87)
The Amiga has one cursor per window, and a mouse pointer. It has its advantages
but when you move the mouse pointer from one window to another and click to
activate it, you have to unfocus on the mouse pointer, and find the cursor
to that window. If you make it bright magenta or something, its possible
but a pain. If you forget this, you startt typing in staring at the mouse
pointer, and of course, the text isn't going where you think it should be.
On the other hand on the Apollo, when I <-- to the start of a line and
go a bit *too* far, I'm out of the window into a new window or just an
empty backdrop.
I dunno, seems like 6 of 1, half dozen of the other.
o
--
Richard Sexton
INTERNET: richard@gryphon.CTS.COM
UUCP: {akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richardbobr@zeus.UUCP (06/15/87)
In article <713@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes:
The Amiga has one cursor per window, and a mouse pointer. It has its
advantages but when you move the mouse pointer from one window to
another and click to activate it, you have to unfocus on the mouse
pointer, and find the cursor to that window. If you make it bright
magenta or something, its possible but a pain. If you forget this, you
startt typing in staring at the mouse pointer, and of course, the text
isn't going where you think it should be.
But of course, you're making the tacit assumption that text should always go
where the pointer cursor sits--an assumption whose realization I've seen
ONLY on Apollo workstations. On the other hand, it is generally true that
each window in a multiwindow environment has the notion of a last active
input point, and with many Apollo applications, it's real simple--look in
the input pad. Alternatively, move the pointing cursor to where you want
text. If the alpha cursor isn't there, then do a selection to move it there.
I dunno, seems like 6 of 1, half dozen of the other.
Hardly!
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK