root%bostonu.csnet@csnet-relay.arpa (BostonU SysMgr) (04/05/85)
We are starting to get systems that will emulate some terminal in a window but are quite willing to create arbitrary height/width which is nice. The obvious problem is telling TERMCAP about all this. The 'hack' solution is to 'printenv > foo', change foo, source foo (csh.) This is a nuisance but works. What occurs to me is to create environment variables HEIGHT and WIDTH and thus it's a simple matter of a 'setenv' to change things which is pretty easy to get the workstation to send or to type in. The tgetnum() routine could be changed so if it is asked for co or li it can check these first (or maybe a new cap added like a bool CV,LV for column variable, line variable or whatever though the first is more transparent.) This is all far too trivial to bother this list about, my real question is: This must have been solved several times, how? Standards? -Barry Shein, Boston University P.S. Yes I know TOPS-20 has this (I always get those kind of answers!)
gwyn@Brl-Vld.ARPA (VLD/VMB) (04/05/85)
The trouble with such simple schemes is that window sizes change,
and one would like to be able to find out the present window size
at will. As a side-effect of Teletype 5620 DMD software development
and probably Sun Microsystems work on windows, it appears that future
releases of 4.nBSD will store window information in the terminal data
structure and have ioctls for fetching and changing this information.
Here is the interesting part of the 4.2+BSD <sys/ioctl.h> file as it
exists at BRL:
/* ioctl.h 6.6 85/01/03 */
...
/*
* Window size structure
*/
struct winsize {
unsigned short row, col; /* character size of window */
unsigned short xpixel, ypixel; /* pixel size of window */
};
...
#define TIOCGWINSZ _IOR(t, 104, struct winsize) /* get window size */
#define TIOCSWINSZ _IOW(t, 103, struct winsize) /* set window size */
All our screen editors, paginators, etc. have been changed to fetch the
window size, which is (0,0,0,0) if not known, and substitute it for the
termcap co#,li#. Of course if the ioctl fails or if the window size has
not been set, the termcap values are used.faustus@ucbcad.UUCP (04/10/85)
> The trouble with such simple schemes is that window sizes change, > and one would like to be able to find out the present window size > at will. As a side-effect of Teletype 5620 DMD software development > and probably Sun Microsystems work on windows, it appears that future > releases of 4.nBSD will store window information in the terminal data > structure and have ioctls for fetching and changing this information. In fact there is a signal, SIGWINCH, in 4.3 which gets sent whenever a window size changes. It gets propagated over rlogin, so your remote vi's can know when you change your window size on a local sun, for instance... Wayne
wcs@ho95b.UUCP (Bill Stewart) (04/12/85)
Barry Shein at BU asked if there was some way to inform TERMCAP and similar programs about different window sizes, for terminals that support multiple windows, and suggested environment variables as one approach. System V Release 2 and the Teletype 5620 terminal provide some support for this. (The 5620 is the production equivalent of the BLIT bitmapped graphics terminal.) The TERMINFO version of curses recognizes the variables LINES and COLUMNS as the dimensions of the window, and can optionally be compiled to try using the 5620/blit ioctl to check window size. This means that any programs using libcurses.a can know how big windows are (if they bother to ask curses instead of wiring in 24x80), and for programs that don't need curses but just want a screen width (e.g. ls -C), the variables are available. Some of the terminal emulation programs that run on the 5620 will automatically set and export the LINES and COLUMNS variables whenever the window size changes; "emacsterm" exports these, plus TERMCAP, TERM, and TERMINFO so that anything screen-oriented gets the right information. This approach is useful in a remote execution environment, where the program can't always DO an ioctl to the real device, especially if you can pass environment variables. Bill Stewart, ihnp4!ho95c!wcs at AT&T Bell Labs.
leif@erisun.UUCP (Leif Samuelsson) (04/14/85)
In article <179@ucbcad.UUCP> faustus@ucbcad.UUCP writes: > In fact there is a signal, SIGWINCH, in 4.3 which gets sent whenever a > window size changes. It gets propagated over rlogin, so your remote vi's > can know when you change your window size on a local sun, for instance... > > Wayne But how does the remote editor access the new window size values from the local workstation? Can rlogin help with this? Leif Samuelsson Ericsson Information Systems AB ..mcvax!enea!erix!erisun!leif Advanced Workstations Division S-172 93 SUNDBYBERG 59 19 N / 17 57 E SWEDEN
broome@ucbvax.ARPA (Jonathan C. Broome) (04/17/85)
[ 42 ] >> In article <179@ucbcad.UUCP> faustus@ucbcad.UUCP writes: >> > In fact there is a signal, SIGWINCH, in 4.3 which gets sent whenever a >> > window size changes. It gets propagated over rlogin, so your remote vi's >> > can know when you change your window size on a local sun, for instance... >> > >> > Wayne >> >> But how does the remote editor access the new window size values >> from the local workstation? Can rlogin help with this? >> >> Leif Samuelsson Another addition to <sys/ioctl.h> is a structure called `winsize', which holds information on the number of rows/columns and pixels in the current window, and a new set of ioctls (TIOCGWINSZ and TIOCSWINSZ) to manipulate this information so you can use it.... ------------------------------------------------------------------------------- Jonathan C. Broome ...!ucbvax!broome, broome@Berkeley