Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mordor.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!gymble!lll-crg!mordor!jdb
From: j...@mordor.UUCP (John Bruner)
Newsgroups: net.micro.mac
Subject: uw - multi-window terminal emulator
Message-ID: <2719@mordor.UUCP>
Date: Fri, 19-Jul-85 21:26:49 EDT
Article-I.D.: mordor.2719
Posted: Fri Jul 19 21:26:49 1985
Date-Received: Sun, 21-Jul-85 02:41:55 EDT
Distribution: net
Organization: S-1 Project, LLNL
Lines: 44
In the past I have seen a number of articles in "net.micro.mac"
suggesting that someone should implement a multiple-window
terminal emulator on the Macintosh. I have done so (for 4.2BSD
UNIX), and I am posting the result to "net.sources.mac". (The
4.2BSD system must provide IPC and pseudo-terminals, but no
kernel changes are required.)
My program is called "uw". It implements up to seven independent
terminal sessions on a Macintosh connected to a 4.2BSD host by a
serial line. (It also works over dialups; however, it may not work
over a network because XON/XOFF flow control does poorly in network
environments.) It emulates an ADM-31 terminal (a "smart" ADM-3A).
The UNIX side is handled by the programs "uw" (server) and "uwtool"
(used to start new windows from the UNIX end).
The distribution includes the source for the 4.2BSD programs
(imagine, *source* in "net.sources.mac":-). I've only used it on
a VAX, but it should work on any 4.2BSD host. I believe it can be
made to work on any UNIX which supports something like pseudo-
terminals. (For instance, I believe I could make it work on the
PDP-11's in the Purdue Engineering Computer Network. [Sorry. Those
who know me understand why I had to put that in.]) The protocol
is simple (and is described in a header file included in the
distribution), so perhaps someone will try an implementation for
System V (?).
Since "uw" uses pseudo-ttys, I recommend that potential users
contact their system administrators about the effect on the
available ptys. A UNIX system with only 16 pty's won't support
very many copies of "uw" running at once.
I believe "uw" will run on a 128K Macintosh, but I don't have one
available to test it.
There is no warranty, express or implied, associated with this
program. In particular, I cannot promise that it is free from
security loopholes.
There are more things I'd like to do with this program. If the
feedback is positive I'll probably post newer versions later.
--
John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
MILNET: jdb@mordor [j...@s1-c.ARPA] (415) 422-0758
UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site tolerant.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!oliveb!bene!tolerant!maddog
From: mad...@tolerant.UUCP (Bill Arnett)
Newsgroups: net.micro.mac
Subject: Re: uw - multi-window terminal emulator
Message-ID: <125@tolerant.UUCP>
Date: Mon, 29-Jul-85 23:43:16 EDT
Article-I.D.: tolerant.125
Posted: Mon Jul 29 23:43:16 1985
Date-Received: Wed, 31-Jul-85 04:39:07 EDT
References: <2719@mordor.UUCP>
Distribution: net
Organization: Tolerant Systems, Inc. San Jose, CA
Lines: 33
Hurray! Bravo! 2^32 cheers!
This is by far the most useful program that has been posted to the net to date.
Congratulations to John Bruner for a job well done.
I do have a few of suggested enhancements:
- include an Edit menu (for DAs) and support copy and paste (ala MacT)
- horizontal scroll bars so that tall skinny windows can be used more
effectively
- save couple of screenfuls of 'lines off the top' and provide vertical
scroll bars
- window 'zoom': double click on the title bar of a small window
increases it to full size; double click on a full size window restores
it to its original size.
- a way to change a window's title
- when a window is resized, change the termcap of the associated unix
session so that editors like vi don't get confused.
- interpret ^S and ^Q locally (as it is they work too slowly to be useful)
- implement some sort of priority scheme so that long outputs in one
window do not slow down echoing in another (this would be essential
if a download was going on in one window and editing in another).
I have been using uw successfully for several days now. I have had only one
real problem: sometimes when I start up a new window, there is no prompt.
Killing the window doesn't help: when it is created again there is still no
prompt. Even quiting the whole program (shutdown; logout; quit) sometimes
doesn't help. [We run 4.2BSD on a 780].
Again, thanks for a great tool. New versions are eagerly awaited!
--
Bill Arnett {ucbvax}!tolerant!maddog
Tolerant Systems, Inc. San Jose
408/946-5667
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1.chuqui 4/7/84; site apple.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!dual!apple!lsr
From: l...@apple.UUCP (Larry Rosenstein)
Newsgroups: net.micro.mac
Subject: Re: Window 'Zooming'
Message-ID: <12121@apple.UUCP>
Date: Sat, 3-Aug-85 14:33:51 EDT
Article-I.D.: apple.12121
Posted: Sat Aug 3 14:33:51 1985
Date-Received: Mon, 5-Aug-85 07:26:48 EDT
References: <2719@mordor.UUCP> <125@tolerant.UUCP>
Reply-To: l...@apple.UUCP (Larry Rosenstein)
Distribution: net
Organization: Advanced Development Group, Apple Computer
Lines: 38
In article <1...@tolerant.UUCP> mad...@tolerant.UUCP (Bill Arnett) writes:
>...
>I do have a few of suggested enhancements:
> - window 'zoom': double click on the title bar of a small window
> increases it to full size; double click on a full size window restores
> it to its original size.
I have a question.
Everyone seems to agree that a command for expanding the window to
full size and back to original size later is a good idea. The
question is do people like this user interface (double clicking on the
title bar, which is also used in the Microsoft applications)?
Some other possibilities:
- a menu command and keyboard equivalent
- double clicking on the window grow box
- a button (similar to close box) somewhere on the title bar
- a button next to one of the scroll bars (on top of the vertical
scroll bar or to the left of the horizontal one)
In MacApp 0.3, we have implemented the menu command option, but the
primitives are there to support any user interface.
Mail me your vote, and I will summarize the results later.
Thanks.
--
Larry Rosenstein
Apple Computer
UUCP: {nsc, dual, voder, ios, mtxinu}!apple!lsr
CSNET: l...@Apple.CSNET
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1.chuqui 4/7/84; site apple.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!sun!idi!apple!lsr
From: l...@apple.UUCP (Larry Rosenstein)
Newsgroups: net.micro.mac
Subject: Window 'Zooming' (partial results)
Message-ID: <15056@apple.UUCP>
Date: Fri, 9-Aug-85 14:57:58 EDT
Article-I.D.: apple.15056
Posted: Fri Aug 9 14:57:58 1985
Date-Received: Mon, 12-Aug-85 06:42:55 EDT
Organization: Advanced Development Group, Apple Computer
Lines: 71
Well, I received 35 responses to my poll on a user interface for
zooming a window. The results so far are:
double click in title bar 12
double click in grow box 19
click in special icon in title bar 7
menu & command key equivalent 7
These add up to >35 because several people gave second choices.
Some comments that people added:
First, the word 'zooming' was somewhat inaccurate. What I meant was a
command that expands the window to full-screen size when executed once
and shrinks it back to its former size when executed again.
Most of the people who voted for double clicks in the title bar did so
to be consistent with Microsoft's applications. One person voted for
the menu command to be consistent with Jazz.
Most of the people who voted for double clicks in the grow box did so
because they considered zooming to be an extension of growing the
window.
Some people voted for some direct manipulation method and a command
key equivalent for speed. A few people were strongly opposed to a
menu command because all other window manipulations are does using
"controls" in the window.
Two arguments for double clicking in the title bar vs. the grow box
are: (1) the title bar is larger and some part of it is always on the
screen (the grow box might be off the screen); (2) a missed double
click (if you click but accidentally move the mouse) can be more
annoying in the grow box because some applications redraw the entire
window if the window changes size.
One argument for a separate icon on the title bar is that double
clicks are more difficult to perform (especially for a novice user).
A couple of people wanted to see this done in a way that it would work
with existing applications.
Finally, there were a few suggestions for other features: (1) a
send-to-back command; (2) a make-the-window-tiny command; (3) a
cleanup-all-windows-command.
Some editorial comments from me.
Zooming generally involves both moving AND resizing the window so
double clicking in the title bar should be just as mnemonic as in the
grow box. When you first think about it, double clicking in the grow
box seems more mnemonic, however.
Since this operation is a shortcut for experienced users, the argument
about double clicking being more difficult is not too much of an issue.
Making this work with existing applications is not easy, but may be
doable in some form.
We plan on discussing this and other user interface issues with people
working on MacApp and with the Apple Human Factors group to come up
with a "standard".
Thanks for all the feedback. I will still take votes, but I will be
away for a week, so there will be no further results until I get back.--
Larry Rosenstein
Apple Computer
UUCP: {nsc, dual, voder, ios, mtxinu}!apple!lsr
CSNET: l...@Apple.CSNET
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1.chuqui 4/7/84; site apple.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!
bellcore!decvax!decwrl!sun!idi!apple!lsr
From: l...@apple.UUCP (Larry Rosenstein)
Newsgroups: net.micro.mac
Subject: Window Zooming (final results)
Message-ID: <28823@apple.UUCP>
Date: Mon, 2-Sep-85 18:12:28 EDT
Article-I.D.: apple.28823
Posted: Mon Sep 2 18:12:28 1985
Date-Received: Wed, 4-Sep-85 05:53:52 EDT
Organization: Advanced Development Group, Apple Computer
Lines: 60
Here are the final results of the (very unscientific) survey about
mechanisms for 'zooming' a window (making it full-screen size and
later returning it to the original size). My thanks to the people who
responded to the survey.
I received 56 responses; the total number of votes is more than 56
because some people voted for more than 1 item.
The final results are:
double clicking on window title bar 24
double clicking on window grow box 26
separate icon on title bar 12
menu command & command key equivalent 7
Some comments received:
Most of the people who voted for double clicking on the title bar did
so for consistency with Microsoft applications, and because the title
bar is large and easy to hit. (Some part of it is always on the screen.)
Most of the people who voted for double clicking the grow box did so
because they considered zooming to be a logical extension of growing
the window.
Some people pointed out that double clicking can be a difficult
operation for new users. It is easy to make one click but then move
the mouse before the second click so that the double click is not
recognized.
In the case of moving the mouse between clicks, some people pointed
out that doing this on the title bar is less annoying than on the
grow box. The reasons is that growing a window can take a long time
in some applications, while moving a window is handled by a BitBlt
operation.
*****
After talking to the Human Interface Group, we decided to adopt
double clicking in the title bar as the recommended user interface.
The feeling was that compatibility with Microsoft was important, and
that the advantages of hitting the title bar outweighed the slight
mnemonic value of double clicking the grow box. (Zooming, in
general, involves BOTH moving and resizing the window.)
We are still considering the implementation details of this
operation. For example, should we give the user feedback about
whether double clicking in the title bar will work; how should the
program decide what size to make the window; etc. I will post another
message when we have these details settled.
--
Larry Rosenstein
Apple Computer
UUCP: {voder, idi, nsc, ios, mtxinu, dual}!apple!lsr
CSNET: l...@Apple.CSNET