jimpa@f103a.UUCP (01/28/87)
We are looking for something that would allow a user to switch
between several processes. This will require an update of the screen
every time the user select a new process. Since we want this to work
with any kind of software written for SysV, we can't relay on the
software for doing the update. This means that we need some kind of
screen-image of every process kept in memory, wich will be dumped on
the screen before a new process is attached to the terminal. It
isn't possible to make the terminal send it's screen back to the
system. Besides the screen-image, we need a copy of the current
stty settings.
We know that some parts of this can be solved using shl, but how do
we manage the updating of the screen-image?
We are using a NCR Tower-32 and a Tower XP with SVR2.
Anything that has just a little connection to this problem is very
appreciated.
Please reply through net mail.
------------------------------------------------------------------------------
fff !
fffffff F|rsvarets ! In real life: enea!f103a!jimpa
ffff ffff Rationaliserings ! In other life: Jim Svensson
fff Institut. !
ffffffffff iii ! Snail mail: FRI
fff The Swedish ! Box 80008
fff rrrr iii Institute of ! 104 50 STOCKHOLM
fff rrr iii Defence Organization ! SWEDEN
fff rr iii and Management. ! Phone: +46 8 788 95 03
fff rr iii !
------------------------------------------------------------------------------rsr@wvucsb.UUCP (02/12/87)
> Keywords: shl, screenhandling > Xref: wvucsb comp.unix.questions:411 Jim Svensson writes: > > We are looking for something that would allow a user to switch > between several processes. This will require an update of the screen > every time the user select a new process. Since we want this to work > with any kind of software written for SysV, we can't relay on the > software for doing the update. This means that we need some kind of > screen-image of every process kept in memory, wich will be dumped on > the screen before a new process is attached to the terminal. It > isn't possible to make the terminal send it's screen back to the > system. Besides the screen-image, we need a copy of the current > stty settings. There is a window manager program called, appropriately enough, wm. It allows you to interactively create a number of windows, each of which can contain a separate process. As you move between windows/processes, the output on these windows is restored, so it appears just the way it was when you last left it. The program was sent down the net quite some time ago. Since it uses termcap, it should work on any terminal having a termcap entry. I'm attaching a portion of the man for reference, below: ----------------------------------------------------------------------------- SEE ALSO R.J.K. Jacob, "User-Level Window Managers for UNIX," Proc. UniForum International Conference on UNIX, pp. 123-133 (1984). AUTHOR Robert J.K. Jacob Naval Research Laboratory Revised by Matt Lennon and Tom Truscott Research Triangle Institute ----------------------------------------------------------------------------- Hope this is of some help. - ravi raman - C.S. Department West Virginia University Morgantown, WV 26506 Phone: (304) 293-3607 pitt!wvucsb!rsr@cadre
guy@gorodish.UUCP (02/15/87)
>There is a window manager program called, appropriately enough, wm. >It allows you to interactively create a number of windows, each of which >can contain a separate process. It also, most likely, does so using pseudo-ttys, which would have to be added to an S5-based system.
jbuck@epimass.UUCP (02/15/87)
Someone wrote: >>There is a window manager program called, appropriately enough, wm. >>It allows you to interactively create a number of windows, each of which >>can contain a separate process. In article <13319@sun.uucp> guy@sun.UUCP (Guy Harris) writes: >It also, most likely, does so using pseudo-ttys, which would have to >be added to an S5-based system. Nope. I used to work with Rob Jacob at Naval Research Laboratory. He produced at least four versions. His first version ran under V6 (!) and had the escape sequences for terminals wired in (termcap hadn't been invented yet, or at least NRL didn't have it yet). On Regent 40 terminals (ugly, but we had a lot of them), the different windows were different shades of grey (you could have four intensities). He converted it to run under termcap; this version used nothing but pipes (like the first) and used two processes per window (kind of like cu) plus the control process (unfortunately, the termcap version doesn't support colored windows). It wasn't blindingly fast, but it was quite elegant. Whoops, that's only three versions. I know there was a fourth. The best-known version does require pseudo-ttys and runs under 4.2bsd, and it's faster than the pipes-and-termcap version, but the others are also available. Check out his Usenix paper; I forget what year. 1983, maybe. Rob, are you out there? -- - Joe Buck {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck Entropic Processing, Inc., Cupertino, California
guy@gorodish.UUCP (02/15/87)
>this version used nothing but pipes (like the first)
Which means it isn't going to understand terminal "ioctl"s, so it
won't know whether the process in question is running in cooked mode
or not. This would drive me crazy (that's partially the reason why I
don't use EMACS windows and why I don't use "commandtool" except for
my console window); I tend to run plenty of non-cooked-mode programs
and I'd expect them to work. (I also tend to do "su" fairly often,
and I expect *that* not to print my password.)
Yes, you can probably cook something up to do windows on a system so
depressingly vanilla that it doesn't have pseudo-ttys. The question
is whether you'd want to use it; I know I wouldn't, but somebody out
there might find it to be such a big win that they'd be willing to
put up with the inconveniences.