allbery@ncoast.UUCP (Brandon Allbery) (06/17/86)
Expires: Quoted from <562@bcsaic.UUCP> ["Re: windows on normal terminals"], by michaelm@bcsaic.UUCP (michael maxwell)... +--------------- | In article <395@dg_rtp.UUCP> throopw@dg_rtp.UUCP (Wayne Throop) writes: | If I understand correctly, part of the reason that large bit-mapped screens | (like the Sun I'm priveleged to be typing on now) are so expensive is the cost | of producing a CRT w/ the requisite resolution; the memory for each pixel is | presumably less of a problem these days (?). It's always seemed to me that | there must be a way of setting up a number of 80x24 CRTs to have at least | some of the advantages of the multiple (8 1/2) screens I have on my Sun right | now. Sure, you couldn't have a single large screen w/ 200 columns x 100 lines, | but you could at least have multiple editor windows (each larger than 1/8th of | a 80x24 screen), a screen dedicated to a running program that you're debugging, | etc., and file transfer between them. Just giving one user multiple terminals | is not sufficient, because he would probably rather not have 8 keyboards; so | there would have to be some easy way of shifting the keyboard from one screen | to another (maybe by numbered function keys, which I stubbornly refuse to use | for editors etc.!) | Surely someone else has thought of this. Any experience? +--------------- Indeed someone has. It's called ``shell layers.'' Unfortunately, the only terminal on which it's worth sh*t is -- YOU GOT IT! A large, expensive bitmapped-screen terminal, yclept DMD5620. It's enough to make a Unix person throw up. --Brandon -- ihnp4!sun!cwruecmp!ncoast!allbery ncoast!allbery@Case.CSNET ncoast!tdi2!brandon (ncoast!tdi2!root for business) 6615 Center St. #A1-105, Mentor, OH 44060-4101 Phone: +01 216 974 9210 CIS 74106,1032 MCI MAIL BALLBERY (part-time)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/18/86)
In article <1228@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes:
-Indeed someone has. It's called ``shell layers.''
-
-Unfortunately, the only terminal on which it's worth sh*t is -- YOU GOT IT!
-A large, expensive bitmapped-screen terminal, yclept DMD5620.
"Shell layers" refers to "shl", which is NOT the same as DMD "layers".
Some people find "shl" useful; it doesn't require any special terminal.
Its main problem is that it merely multiplexes the terminal for several
concurrent processes, which have no way to tell what may be visible on
the current display. A full window manager solves this problem.mikel@codas.ATT.UUCP (Mikel Manitius) (06/20/86)
> "Shell layers" refers to "shl", which is NOT the same as DMD "layers". > Some people find "shl" useful; it doesn't require any special terminal. > Its main problem is that it merely multiplexes the terminal for several > concurrent processes, which have no way to tell what may be visible on > the current display. A full window manager solves this problem. You can very easily tell what is on your screen, if you do "stty loblk". This blocks processes which try to output to the terminal, if they are not in the current layer. When the layer becomes current, then they job is unblocked, and you may get flooded with output. In my opinion, this is still not as nice as berkeley's job control, but to get that, you must give up other things.... -- Mikel Manitius @ AT&T-IS Altamonte Springs, FL ...{seismo!akgua|ihnp4|cbosgd}!codas!mikel.ATT.UUCP
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/24/86)
In article <574@codas.ATT.UUCP> mikel@codas.ATT.UUCP (Mikel Manitius) writes:
-> "Shell layers" refers to "shl", which is NOT the same as DMD "layers".
-> Some people find "shl" useful; it doesn't require any special terminal.
-> Its main problem is that it merely multiplexes the terminal for several
-> concurrent processes, which have no way to tell what may be visible on
-> the current display. A full window manager solves this problem.
-
-You can very easily tell what is on your screen, if you do "stty loblk".
-This blocks processes which try to output to the terminal, if they are
-not in the current layer. When the layer becomes current, then they job
-is unblocked, and you may get flooded with output.
Rong; that's not what I was talking about. Try running two concurrent
"vi"s under "shl" and see what good "stty loblk" does you.
-In my opinion, this is still not as nice as berkeley's job control, but
-to get that, you must give up other things....
Job control is a massive hack that doesn't work well in a general
environment where daemons have equal rights with humans, where
there are several candidates for a process's "controlling terminal",
where it is not clear whether a net port constitutes a "terminal" or
not, etc. Like many Berkeley features, it is nice so long as one lives
within the restricted usage model that it was based on. In any case,
HP-UX has a System V-compatible implementation of BSD-style job
control. What are the "other things" one supposedly has to give up?