Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!dayton!ems!minnow!lee
From: l...@minnow.UUCP
Newsgroups: comp.unix.questions
Subject: Multiscreen on Unix
Message-ID: <910@minnow.UUCP>
Date: Tue, 2-Jun-87 08:44:39 EDT
Article-I.D.: minnow.910
Posted: Tue Jun 2 08:44:39 1987
Date-Received: Fri, 5-Jun-87 01:44:33 EDT
Reply-To: l...@A60.UUCP (Gene Lee )
Organization: Unisys Corporation - Roseville, MN
Lines: 17
xxxxxx
I would like to have multiple screens on Unix the way I do on
SCO Xenix and Microport Unix.
1). Has anyone written something do this?
2). Does anyone have any ideas on how to approach doing this?
Thanks in advance
--
Gene Lee UUCP: ...ihnp4!{meccts,dayton,rosevax}!ems!minnow!lee
UNISYS Corporation ATT: (612) 635-6334
If not for the courage of the fearless crew, the minnow would be lost.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!hc!beta!cmcl2!
brl-adm!brl-smoke!gwyn
From: g...@brl-smoke.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <5942@brl-smoke.ARPA>
Date: Wed, 3-Jun-87 23:55:25 EDT
Article-I.D.: brl-smok.5942
Posted: Wed Jun 3 23:55:25 1987
Date-Received: Sat, 6-Jun-87 05:36:19 EDT
References: <910@minnow.UUCP>
Reply-To: g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 11
In article <9...@minnow.UUCP> l...@A60.UUCP (Gene Lee ) writes:
> I would like to have multiple screens on Unix the way I do on
>SCO Xenix and Microport Unix.
The best ways I know of to acquire this facility are to either purchase
a UNIX system with windows integrated into it (such as a Sun workstation)
or acquire an AT&T (nee Teletype) model 5620 (or follow-on whenever it is
finally announced; we've been expecting one for a while) Dot-Mapped Display
terminal and associated UNIX support software. There are also some public-
domain implementations of windowing systems for "dumb" CRTs, although
they're not nearly as spiffy. I imagine others will tell you about those.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!clyde!cbosgd!ihnp4!inuxc!iuvax!bsu-cs!rb442!dhesi
From: dh...@rb442.UUCP (Rahul Dhesi)
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <103@rb442.UUCP>
Date: Fri, 5-Jun-87 17:29:42 EDT
Article-I.D.: rb442.103
Posted: Fri Jun 5 17:29:42 1987
Date-Received: Wed, 10-Jun-87 05:58:42 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA>
Reply-To: dh...@rb442.UUCP (Rahul Dhesi)
Organization: CS Dept., Ball State University, Muncie, Indiana
Lines: 40
Summary: *mild flame* against fancy windows with dumb borders
Followup-To:
l...@A60.UUCP (Gene Lee ) writes:
> I would like to have multiple screens on Unix the way I do on
^^^^^^^^ ^^^^^^^
>SCO Xenix and Microport Unix.
g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) replies:
>The best ways I know of to acquire this facility are to either purchase
>a UNIX system with windows integrated into it (such as a Sun workstation)
^^^^^^^
>or acquire an AT&T (nee Teletype) model 5620 (or follow-on whenever it is
>finally announced; we've been expecting one for a while) Dot-Mapped Display
>terminal and associated UNIX support software. There are also some public-
>domain implementations of windowing systems for "dumb" CRTs, although
^^^^^^^^^ ^^^^^^^
>they're not nearly as spiffy. I imagine others will tell you about those.
Windows and multiple screens are not the same thing.
My UNIX PC has windows. You can create them, then you can reshape them
and move them.
My Microport System V/AT has multiple screens. You can's reshape them
amd move them.
The difference is like night and day. On my UNIX PC, it's so much
of a bother to use multiple windows that I got rid of them altogether.
It's no fun pressing keys here and there, then finding the mouse,
then location a corner here and here, and then finally (a few minutes
later) getting a new window to work in.
On my Microport system, I can hit a key and be working on a fresh new screen
in about 50 milliseconds. I don't waste time finding keys and mice, and
I don't waste screen space on fancy but useless borders.
Now, I don't know how Sun implements its windows, and I'm sure they are
implemented better than they are on the UNIX PC. But it's good to be precise
in our terminlogy, and I just wanted to emphasize that:
WINDOWS AND MULTIPLE SCREENS ARE NOT THE SAME THING.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: g...@gorodish.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <20550@sun.uucp>
Date: Sun, 7-Jun-87 04:23:02 EDT
Article-I.D.: sun.20550
Posted: Sun Jun 7 04:23:02 1987
Date-Received: Sun, 7-Jun-87 20:03:59 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA> <103@rb442.UUCP>
Sender: n...@sun.uucp
Lines: 66
> Windows and multiple screens are not the same thing.
>
> My UNIX PC has windows. You can create them, then you can reshape them
> and move them.
>
> My Microport System V/AT has multiple screens. You can's reshape them
> amd move them.
I presume "You can's reshape them and move them" really should have
read "You can't reshape them or move them".
> The difference is like night and day. On my UNIX PC, it's so much
> of a bother to use multiple windows that I got rid of them altogether.
> It's no fun pressing keys here and there, then finding the mouse,
> then location a corner here and here, and then finally (a few minutes
> later) getting a new window to work in.
>
> On my Microport system, I can hit a key and be working on a fresh new screen
> in about 50 milliseconds. I don't waste time finding keys and mice, and
> I don't waste screen space on fancy but useless borders.
There is nothing about a window system that obliges you to have
"fancy but useless borders". There is also nothing about a window
system that obliges you to use mice or multiple keystrokes (you will
*still* have to find the one key that gets you a new screen, even on
your Microport system, although it may be placed so that "finding" it
is trivial) to create a new window, or that requires the creation of
a window to take minutes. (Yes, I know, SunView puts stuff on the
borders and can take a while to create windows, and may not make it
possible to pop up a new window and move to that window in one
keystroke. I'm saying what's possible here.)
> But it's good to be precise in our terminlogy, and I just wanted to
> emphasize that:
>
> WINDOWS AND MULTIPLE SCREENS ARE NOT THE SAME THING.
Multiple screens are just windows that are obliged to cover the
entire screen; in other words, a multiple-screen system is just a
window system with a number of restrictions. The only fundamental
difference between a multiple-screen system and a general window
system is that a multiple-screen system doesn't have to arrange to
multiplex the display, and can possibly use tricks to multiplex the
keyboard.
The person requested multiple screens "on UNIX". The only way to do
this "on UNIX", rather than on a particular UNIX machine or set of
UNIX machines, is to assume that all you have available is a dumb
terminal. Doing so requires you to do things like maintaining
virtual screens, separate from the physical screen; after doing this,
the extra work of supporting non full-screen windows isn't much. All
that you'd get from not making that step is that you wouldn't have to
worry about having programs capable of dealing with variable-size
screens, and there are even ways of providing some of that by playing
games with things like the TERMCAP or TERMINFO environment variables.
In the particular case of a PC, there may be tricks you can play with
multiple screens that won't work with windows. The programs running
in the "active" window can be given direct access to the screen, and
when switching screens you can just copy the entire screen image to a
holding buffer; you could just freeze programs running in inactive
windows, and thus not have to worry about multiplexing input or
output.
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: g...@gorodish.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <20551@sun.uucp>
Date: Sun, 7-Jun-87 04:29:12 EDT
Article-I.D.: sun.20551
Posted: Sun Jun 7 04:29:12 1987
Date-Received: Sun, 7-Jun-87 20:04:32 EDT
References: <910@minnow.UUCP>
Sender: n...@sun.uucp
Lines: 98
> I would like to have multiple screens on Unix the way I do on
> SCO Xenix and Microport Unix.
The only way to do multiple screens "on UNIX", rather than on a
particular UNIX machine or set of UNIX machines, is to assume that
all you have available is a dumb terminal. There's a fair bit of
work involved in this.
> 1). Has anyone written something do this?
Various people have done this; Mark Horton wrote a window system
whose source can be found in the System V, Release 3.0 source
distribution in the directory "/usr/src/lib/libcurses/demo/window".
(Various games, including what appears to be a version of the Space
Invaders game supplied with 4.1BSD, can also be found in the "demo"
directory.) I think there may have been such a window system
supplied with the 4.3BSD alpha tape, or something like that; I don't
see it in any obvious place in the 4.3BSD distribution.
> 2). Does anyone have any ideas on how to approach doing this?
If a program is writing to screen 1, while screen 2 is the
screen currently being displayed, some window manager must keep track
of the "virtual" screen 1. This either means that:
1) the window manager must be able to recognize all the
various control sequences that can be sent to any of the
terminals it supports - it could do a lot of this by
reading the "termcap" or "terminfo" description for that
terminal (idea courtesy of Dave Rosenthal's "psterm"
terminal emulator for NeWS), but this would require that
no program use any sequence other than the ones in the
description (which may very well be the case)
or
2) the window manager will have to emulate a virtual
terminal of some sort, accepting sequences for that
virtual terminal as input and updating the physical
display using e.g. "curses". (Mark Horton's window
system works this way.)
Both of these strategies are best done using some sort of pseudo-tty
mechanism, which is not supplied with vanilla System V, but appears
in 4.[23]BSD and a lot of other UNIX systems (including lots of
System V-compatible systems). (There may be ways of doing this with
pipes, but there are some problems with that - see below.)
Also, the window manager would have to intercept input from the
terminal, in order to know when to switch windows/screens, unless you
added a new "switch windows" character to the tty driver and arranged
to have some event, such as a signal, delivered to the window manager
when this character was typed, without affecting any programs running
in the window.
If this trick were used, the window manager would somehow have to
"freeze" programs running in inactive windows/screens, to prevent
them from reading from the keyboard, or would have to use some
mechanism such as the "sxt" devices used by shell layers to multiplex
screens. ("sxt" devices would also provide the "switch" character
for switching "shell layers", which could be used to switch between
windows/screens instead - alas, "sxt"s have NO mechanism for
multiplexing output, so you'd have to have something like pseudo-ttys
for this.)
If you have pseudo-terminals, you can use them for input multiplexing
and capturing the screen-switching commands as well. If not, you
might be able to cobble something together with "sxt"s and pipes,
although some programs might get confused if their standard input
were an "sxt" and their standard output and error were pipes - some
would think they were at a terminal and behave correctly, some
wouldn't and wouldn't act correctly (e.g., not line-buffering their
output), and some might work half-correctly.
Note that pipes could not substitute for pseudo-ttys on the *input*
side, unless you're willing to sacrifice a lot of things; pipes don't
do erase/kill processing, and don't pass "ioctl"s through, so the
window manager would either always have to do the erase/kill
processing, never do it, or be told via a special window-manager
command whether to do it or not. Would you rather not be able to
correct typing errors, not be able to run screen editors (or other
non-cooked-mode programs) inside a window, or be obliged to switch
modes when entering and leaving screen editors? Some programs that
do "isatty(0)" to see if they're being run from a terminal (i.e.,
interactively) would get confused as well.
A way of getting around this would be some way of running full-screen
programs from the window manager, rather than from a shell in a
window. The window manager would make the current screen no longer
be the active screen, without making any other screen the active
screen, and would also hand control of the keyboard over to the
program in question. When that program exited, it would reclaim
control of the keyboard and would make the current screen the active
screen again. Of course, this means that when you're running a
full-screen program, you don't have multiple screens or windows....
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ptsfa!ihnp4!inuxc!
iuvax!pur-ee!newton.physics.purdue.edu!pur-phy!mrstve!rjk
From: r...@mrstve.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <696@mrstve.UUCP>
Date: Tue, 9-Jun-87 18:59:18 EDT
Article-I.D.: mrstve.696
Posted: Tue Jun 9 18:59:18 1987
Date-Received: Sat, 13-Jun-87 02:34:57 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA> <103@rb442.UUCP>
<20550@sun.uucp>
Reply-To: r...@mrstve.UUCP (Richard Kuhns)
Organization: Mr sTVe's, Lafayette IN
Lines: 32
In article <20...@sun.uucp> guy%gorod...@Sun.COM (Guy Harris) writes:
>The person requested multiple screens "on UNIX". The only way to do
>this "on UNIX", rather than on a particular UNIX machine or set of
>UNIX machines, is to assume that all you have available is a dumb
>terminal. Doing so requires you to do things like maintaining
>virtual screens, separate from the physical screen; after doing this,
>the extra work of supporting non full-screen windows isn't much. All
>that you'd get from not making that step is that you wouldn't have to
>worry about having programs capable of dealing with variable-size
>screens, and there are even ways of providing some of that by playing
>games with things like the TERMCAP or TERMINFO environment variables.
> Guy Harris
> {ihnp4, decvax, seismo, decwrl, ...}!sun!guy
> g...@sun.com
Has anyone done anything like this with STREAMS-oriented tty drivers?
It seems to me that windows/multiple screens would be relatively
easy to implement by just PUSHing an appropriate module onto the
stream that controlled your physical terminal that kept track of
what was on your (physical) screen at all times, similar to curses.
It could also be handy to have a `virtual' screen of, say, 66 lines,
allowing one to scroll both up and down.
The more I think about it, the more I could do with a STREAM-based
tty driver. Now all I need do is figure out how to get one...
--
!pur-ee!pur-phy!mrstve!rjk
Rich Kuhns {ihnp4, decvax, etc...}
!itivax!mrstve!rjk
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!hao!ames!oliveb!
sun!gorodish!guy
From: g...@gorodish.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <20837@sun.uucp>
Date: Wed, 10-Jun-87 15:59:11 EDT
Article-I.D.: sun.20837
Posted: Wed Jun 10 15:59:11 1987
Date-Received: Sat, 13-Jun-87 05:36:41 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA> <103@rb442.UUCP>
<696@mrstve.UUCP>
Sender: n...@sun.uucp
Lines: 28
> Has anyone done anything like this with STREAMS-oriented tty drivers?
> It seems to me that windows/multiple screens would be relatively
> easy to implement by just PUSHing an appropriate module onto the
> stream that controlled your physical terminal that kept track of
> what was on your (physical) screen at all times, similar to curses.
"Relatively easy"? "Similar to curses"? "curses" is a pretty big
library, and even something just handling this would be pretty big.
It would either have to implement a virtual terminal, and support
*lots* of different kinds of physical terminals, or would have to
keep track of the screen image by understanding how the physical
terminal works, and would still have to support lots of different
kinds of physical terminals.
STREAMS modules live in the kernel, and I don't want something that
big living in my kernel. (There are enough big things living there
already.) Furthermore, it would also have to maintain a copy of the
screen, which means even more big things in the kernel.
Sorry, but putting this into a STREAMS module would be the wrong
thing to do. Pseudo-ttys make much more sense, since most of the
support can be moved into user mode. Under the right circumstances,
a STREAMS-based tty driver could make it easier to do pseudo-ttys; a
pseudo-tty might be something similar to a streams pipe, with any
other modules pushed atop the "slave" side.
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!hao!ames!oliveb!
sun!gorodish!guy
From: g...@gorodish.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <20837@sun.uucp>
Date: Wed, 10-Jun-87 15:59:11 EDT
Article-I.D.: sun.20837
Posted: Wed Jun 10 15:59:11 1987
Date-Received: Sat, 13-Jun-87 05:36:41 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA> <103@rb442.UUCP>
<696@mrstve.UUCP>
Sender: n...@sun.uucp
Lines: 28
> Has anyone done anything like this with STREAMS-oriented tty drivers?
> It seems to me that windows/multiple screens would be relatively
> easy to implement by just PUSHing an appropriate module onto the
> stream that controlled your physical terminal that kept track of
> what was on your (physical) screen at all times, similar to curses.
"Relatively easy"? "Similar to curses"? "curses" is a pretty big
library, and even something just handling this would be pretty big.
It would either have to implement a virtual terminal, and support
*lots* of different kinds of physical terminals, or would have to
keep track of the screen image by understanding how the physical
terminal works, and would still have to support lots of different
kinds of physical terminals.
STREAMS modules live in the kernel, and I don't want something that
big living in my kernel. (There are enough big things living there
already.) Furthermore, it would also have to maintain a copy of the
screen, which means even more big things in the kernel.
Sorry, but putting this into a STREAMS module would be the wrong
thing to do. Pseudo-ttys make much more sense, since most of the
support can be moved into user mode. Under the right circumstances,
a STREAMS-based tty driver could make it easier to do pseudo-ttys; a
pseudo-tty might be something similar to a streams pipe, with any
other modules pushed atop the "slave" side.
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!mordor!lll-tis!
ptsfa!ihnp4!inuxc!iuvax!pur-ee!newton.physics.purdue.edu!pur-phy!mrstve!rjk
From: r...@mrstve.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <699@mrstve.UUCP>
Date: Thu, 18-Jun-87 19:12:39 EDT
Article-I.D.: mrstve.699
Posted: Thu Jun 18 19:12:39 1987
Date-Received: Sat, 20-Jun-87 07:06:51 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA> <103@rb442.UUCP>
<696@mrstve.UUCP> <20837@sun.uucp>
Reply-To: r...@mrstve.UUCP (Richard Kuhns)
Organization: Mr sTVe's, Lafayette IN
Lines: 36
In article <20...@sun.uucp> guy%gorod...@Sun.COM (Guy Harris) writes:
(earlier, I wrote)
>> Has anyone done anything like this with STREAMS-oriented tty drivers?
>> It seems to me that windows/multiple screens would be relatively
>> easy to implement by just PUSHing an appropriate module onto the
>> stream that controlled your physical terminal that kept track of
>> what was on your (physical) screen at all times, similar to curses.
>
>"Relatively easy"? "Similar to curses"? "curses" is a pretty big
>library, and even something just handling this would be pretty big.
>It would either have to implement a virtual terminal, and support
>*lots* of different kinds of physical terminals, or would have to
>keep track of the screen image by understanding how the physical
>terminal works, and would still have to support lots of different
>kinds of physical terminals.
[...]
> Guy Harris
> {ihnp4, decvax, seismo, decwrl, ...}!sun!guy
> g...@sun.com
I didn't mean to emulate the entire curses library -- I just want to
keep track of what is on 1 or more virtual screens (via an array/structure
indicating size/location/etc). On receipt of (say) a certain escape
sequence, the appropriate module of the terminal driver would redraw
the physical screen so it looked like the requested virtual screen.
The terminal driver shouldn't have to care about the *type* of the
terminal at all -- it just passes whatever terminal control sequences
it receives right on thru (thru to the structure (a queue, maybe), anyhow,
which would later, when requested, just dump to the terminal).
...so I don't always explain myself very well... ...I knew what I meant...
--
!pur-ee!pur-phy!mrstve!rjk
Rich Kuhns {ihnp4, decvax, etc...}
!itivax!mrstve!rjk
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!oliveb!sun!gorodish!guy
From: guy%gorod...@Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <21611@sun.uucp>
Date: Fri, 19-Jun-87 17:37:28 EDT
Article-I.D.: sun.21611
Posted: Fri Jun 19 17:37:28 1987
Date-Received: Mon, 22-Jun-87 04:13:46 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA> <103@rb442.UUCP>
<699@mrstve.UUCP>
Sender: n...@sun.uucp
Lines: 42
> I didn't mean to emulate the entire curses library
Please reread what I said. I never said you had to emulate the
entire curses library, just that you'd have to do enough of the same
thing that you're talking about putting LOTS of stuff into the
kernel.
> -- I just want to keep track of what is on 1 or more virtual screens (via
> an array/structure indicating size/location/etc). On receipt of (say) a
> certain escape sequence, the appropriate module of the terminal driver
> would redraw the physical screen so it looked like the requested virtual
> screen.
OK, so how is it going to "keep track" of what's on the screen? It
can't just blindly remember everything sent to the screen, unless it
remembers everything you sent since you first started talking to that
terminal, or until you last sent the terminal something that *this
module* recognized as somehow resetting the state of the terminal.
Frankly, the notion of redrawing the screen by retransmitting
everything sent to it since the screen was last cleared doesn't
appeal to me somehow; the fact that it's generally transmitted at no
better than 19.2KB, and could thus take a LONG time to redraw, may
have something to do with it. (We won't even discuss the memory
required to hold this information.)
> The terminal driver shouldn't have to care about the *type* of the
> terminal at all -- it just passes whatever terminal control sequences
> it receives right on thru (thru to the structure (a queue, maybe), anyhow,
> which would later, when requested, just dump to the terminal).
See above. Without large amounts of memory on the machine, and large
amounts of patience on the part of the user, this isn't going to work
very well at all.
You can do this sort of thing on PCs because their displays tend to
be memory-mapped, and the kernel could just stash the entire screen
image away somewhere and restore another one from its stored copy;
this takes a bounded amount of memory. Doing this on arbitrary
terminals just won't fly.
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!hal!ncoast!allbery
From: allb...@ncoast.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <2690@ncoast.UUCP>
Date: Sat, 20-Jun-87 17:36:48 EDT
Article-I.D.: ncoast.2690
Posted: Sat Jun 20 17:36:48 1987
Date-Received: Sun, 21-Jun-87 11:57:12 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA> <103@rb442.UUCP>
<696@mrstve.UUCP> <20837@sun.uucp> <699@mrstve.UUCP>
Reply-To: allb...@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.unix.questions
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 27
As quoted from <6...@mrstve.UUCP> by r...@mrstve.UUCP (Richard Kuhns):
+---------------
| I didn't mean to emulate the entire curses library -- I just want to
| keep track of what is on 1 or more virtual screens (via an array/structure
| indicating size/location/etc). On receipt of (say) a certain escape
| sequence, the appropriate module of the terminal driver would redraw
| the physical screen so it looked like the requested virtual screen.
|
| The terminal driver shouldn't have to care about the *type* of the
| terminal at all -- it just passes whatever terminal control sequences
| it receives right on thru (thru to the structure (a queue, maybe), anyhow,
| which would later, when requested, just dump to the terminal).
+---------------
Ah, but it does! How is the protocol module to know that ESC [ is a lead-in
for an escape sequence on ANSI terminals and "position cursor to row" (may
be column?) on Wyse 50's? It'll get the current cursor position wrong if
it treats ESC [1;1H as "home" when the Wyse 50 moves to line 18 and prints
";1H".
--
Copyright (C) 1987 Brandon S. Allbery. Redistribution permitted only if the
redistributor permits further redistribution. (Stargate take heed!)
---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ----
Brandon S. Allbery {decvax,cbosgd}!cwruecmp!ncoast!allbery
aXcess Company {ames,mit-eddie,talcott}!necntc!ncoast!allbery
6615 Center St. #A1-105 necntc!ncoast!allb...@harvard.HARVARD.EDU
Mentor, OH 44060-4101 +01 216 974 9210 (also eddie.MIT.EDU)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: ch...@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <7173@mimsy.UUCP>
Date: Tue, 23-Jun-87 10:32:17 EDT
Article-I.D.: mimsy.7173
Posted: Tue Jun 23 10:32:17 1987
Date-Received: Thu, 25-Jun-87 03:17:09 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA> <103@rb442.UUCP>
<2690@ncoast.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 21
>As quoted from <6...@mrstve.UUCP> by r...@mrstve.UUCP (Richard Kuhns):
>+---------------
>| I didn't mean to emulate the entire curses library -- I just want to
>| keep track of what is on 1 or more virtual screens....
>+---------------
In article <2...@ncoast.UUCP> allb...@ncoast.UUCP (Brandon Allbery) writes:
>Ah, but it does! How is the protocol module to know that ESC [ is a lead-in
>for an escape sequence on ANSI terminals and "position cursor to row" (may
>be column?) on Wyse 50's?
I am not sure I should be feeding this discussion, but I would point
out that this is not necessary. Any screen management system, whether
user or kernel based, can provide a virtual terminal with a private
termcap to each separate screen or window. The protocol module could
interpret ANSI sequences, while the ultimate screen refersh is done
with Wyse sequences. (The Maryland Window System, which was all user
code, worked this way.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: ch...@mimsy.umd.edu Path: seismo!mimsy!chris