weamc@pyuxa.UUCP (12/05/83)
I am not sure that the problem is in hardware. I run my terminal hooked
to my computer at home at 9600 baud, and I can draw amy kind of menu
I like. Personally, I think that ASCII terminals are an elegant solution
to a very difficult problem, and I do not think that bit-mapped terminals
are the answer. Look at the chaos in micros, with everybody implementing
their own version of screen-handling. Software becomes very unportable.
A higher baud rate will partially solve the delay problem with menus, and
the rest of it will be solved by better use of the cursor-addressing
features of terminals. Many programs (written more than two or three
years ago) do not use cursor-addressing, so they put out many time-wasting
blanks.
As for bit-mapped graphics and "windows," I think the jury is still out.
Windows are cute, exercise and demonstrate the graphics capability of a
system, and the idea is the latest buzzword, but a higher baud rate
(i.e. the ability to re-write the screen quickly with another application)
will address most of the issues that windows supposedly address. Does
anyone recall if Xerox ever did any research to indicate that windows
improve human performance?????
Andy Cohillrene@umcp-cs.UUCP (12/07/83)
>> As for bit-mapped graphics and "windows," I think the jury is still out. >>Windows are cute, exercise and demonstrate the graphics capability of a >>system, and the idea is the latest buzzword, but a higher baud rate >>(i.e. the ability to re-write the screen quickly with another application) >>will address most of the issues that windows supposedly address. Does >>anyone recall if Xerox ever did any research to indicate that windows >>improve human performance????? >> Andy Cohill I thought the idea of windows was to address a problem that non-programmer users complained of - the lack of a cluttered desk. The people buying systems for their office sort of liked having little bits of paper strewn around to remind them of tasks they need to do, with the current one on top of the clutter. When I saw a demonstration of SCION's (neato!) Superscreen (I suppose it's copyrighted or something), they told me all the windows flipping on top of one another and crawling around the screen and changing size and so forth were to recreate the cluttered desk of the busy executive. - rene -- "Peoles have feeelings, too" Arpa: rene.umcp-cs@CSNet-relay Uucp:...{allegra,seismo}!umcp-cs!rene
dave@rocksvax.UUCP (Dave Sewhuk) (12/08/83)
You think that today's ASCII terminals are OK for menus!! You can have
at most 1920 characters of context on this menu in a single font.
Having used screen editors with real windows on bit mappped displays to
put together documents based from data in 3 files I would say that you
do not have enough context to help you. Consider you need 2 lines of
that 24 line screen to lay down box edges to define the edges of the
file windows that leaves you with only 580 characters for equal
windows. That is only 7 lines of text. Also ASCII terminals have to
send keystrokes to down serially. To scroll around you have to
use those blasted awful "arrow" keys, or commands to jump you from
window to window, no thanks. I like having lots of context, it saves
me from making as many hardcopies, plus the ability to stuff text from
one window to another with the mouse. It is nice to see that structure
in on that .h file in one window and the thing your working on in
another. You tend to get things spelled correctly.
I think we need better hardware than plain ASCII terminals to do that
job. Also consider that it is hell on the vt100 to send half of those
commands. They involve sending some 5 bytes of data to do one little
operation. That and no vt100 runs at 960 cps throughput. They all run
throughputs on the order of 480 cps on plain text. Those fancy scroll
functions take many milliseconds to run after you get those 5 bytes there.
It makes a busy screen take a long time
to get the cursor to move or scrolling seems sluggish. When I see things
taking a long time I get restless, not a good mode to running in.
--
Dave
Arpa: Sewhuk.HENR@PARC-MAXC.ARPA
uucp: {allegra, rochester, ritcv, ritvp, amd70, sunybcs}!rocksvax!davehenry@utzoo.UUCP (Henry Spencer) (12/08/83)
Being able to re-write the screen quickly with another application
will not solve the problem of wanting to look at both *simultaneously*.
The key point of windows is not flipping back and forth but being able
to attend to multiple activities *without* flipping back and forth.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry