lai@vedge.UUCP (David Lai) (12/01/88)
2 problems: 1) How is a program able to tell the size of a pseudoterm's window. Is there a termcap entry which specifies that the screen can be resized? (The termcap man pages dont mention it). How does a program get 'signalled' when a resize occurs (ie. like vi doing a redraw after a resize) ? 2) How can the termcap be modified automatically when a 'resize' occurs, when not in a program (ie at the shell prompt)? This would be useful so that the next 'ls' or other such commands would output an appropriate number of columns. I am looking for a general case solution which should be able to be applied to various windowing systems. Does this involve a special tty/pty driver? -- "What is a DJ if he can't scratch?" - Uncle Jamms Army The views expressed are those of the author, and not of Visual Edge, nor Usenet. David Lai (vedge!lai@larry.mcrcim.mcgill.edu || ...watmath!onfcanim!vedge!lai)
dave@cs.wisc.edu (Dave Cohrs) (12/02/88)
In article <2081@vedge.UUCP> lai@vedge.UUCP (David Lai) asks about window sizes. In 4.3BSD and related systems (SunOS 4.0 and Ultrix too), the current size of a window is kept as part of the per-tty information, and you can get/set it via a couple ioctls: #include <sys/ioctl.h> int getwinsz() { struct winsize ws; ioctl(f, TIOCGWINSZ, &ws); printf("current window size: %d x %d chars, %d x %d pixels\n", ws.ws_row, ws.ws_col, ws.ws_xpixel, ws.ws_ypixel); return 0; } The ioctl to set the window size is TIOCSWINSZ (f would be the fd of your tty). If you want to be signal()ed when some process changes your window size, you use the SIGWINCH signal. signal(SIGWINCH, getwinsz); /* your types may vary */ In this case, getwinsz() will be called whenever someone, like xterm changes your window size. There is an equivalent but different pair of ioctls on older SunOS's. There doesn't appear to be such functionality in SystemV (they have a different philosophy about what a window is, I think). The TERMCAP variable won't automatically change. If you have X, then you have a "resize" program, and you can use it to change your TERMCAP variable. Of course, if you have an "ls" that look as your window size, it should use the ioctl() as well, not just TERMCAP. I suppose you could hack your shell to change the TERMCAP variable for you. dave cohrs -- Dave Cohrs +1 608 262-6617 UW-Madison Computer Sciences Department dave@cs.wisc.edu ...!{harvard,rutgers,ucbvax}!uwvax!dave
guy@auspex.UUCP (Guy Harris) (12/02/88)
>1) How is a program able to tell the size of a pseudoterm's window. Many systems have adopted the 4.3BSD TIOCGWINSZ "ioctl"; the kernel stores the screen size along with the tty modes. SunOS 3.2 and later has it, and I'd suspect many of the other "started with BSD" UNIX systems do as well. (Some may have stuck at 4.2BSD level, though, and haven't picked it up.) SunOS releases prior to 3.2 had TIOCGSIZE, which was a Sun invention which antedated 4.3BSD (for better or worse, Berkeley didn't pick Sun's version up). (Yes, I know it's not in the 3.x documentation, but it is there, along with "stty size", "stty rows", and "stty cols".) > Is there a termcap entry which specifies that the screen can be > resized? (The termcap man pages dont mention it). No, and that's why the "termcap" man pages don't mention it. Instead, you have: 1) the Sun mechanism, wherein the "termcap" library code does a TIOCGSIZE or TIOCGWINSZ, and if the sizes it gets back are non-zero, it ignores the ones in the "termcap" entry and uses the ones from the "ioctl"; 2) the 4.3BSD mechanism, where this is left up to the code that uses the "termcap" library routines; "curses" does it for you, but programs that don't use "curses", such as "vi", have to be modified to do the "ioctl" and override the values in the "termcap" entry. (In SunOS the S5 "curses"/"terminfo" library takes approach 1), so applications don't have to know about it.) > How does a program get 'signalled' when a resize occurs (ie. like vi > doing a redraw after a resize) ? If the window size for a pseudo-tty is changed, a SIGWINCH signal is delivered to the process group for that pseudo-tty. >2) How can the termcap be modified automatically when a 'resize' occurs, when > not in a program (ie at the shell prompt)? This would be useful so that > the next 'ls' or other such commands would output an appropriate number > of columns. With difficulty, at best. The 4.3BSD scheme, and the SunOS scheme which preceded it, render this unnecessary, since software that cares how big the screen is tries the "ioctl" first and, only if it returns zero for the sizes, uses the value from the "termcap" entry. >I am looking for a general case solution which should be able to be >applied to various windowing systems. Does this involve a special >tty/pty driver? The technique described above requires: 1) a tty/pty driver which supports TIOCGWINSZ/TIOCSWINSZ or equivalents (such as the older SunOS TIOCGSIZE/TIOCSSIZE); 2) a SIGWINCH signal, and some way for it to be delivered when the window size is changed (if you do the 4.3BSD TIOCSWINSZ "ioctl", which sets the sizes, on either the master or slave side, the tty driver delivers a SIGWINCH if the sizes are actually being changed). 4.3BSD has all this, as does SunOS and, as indicated above, many other "started with BSD" systems. Various System V releases, and other UNIX variants, may have picked it up as well.
guy@auspex.UUCP (Guy Harris) (12/02/88)
>There is an equivalent but different pair of ioctls on older SunOS's. Actually, TIOCGWINSZ/TIOCSWINSZ have been in SunOS since 3.2, although they weren't documented until 4.0. The pre-4.0 version didn't store the "pixel" sizes, but just returned them as zero. >There doesn't appear to be such functionality in SystemV (they have >a different philosophy about what a window is, I think). No, it's just that they don't have pseudo-ttys; pseudo-ttys are actually a general mechanism; many window systems use them to provide "terminal emulator" windows. S5 doesn't come standard with a window system (unless S5R3.2 comes standard with X11), so it really doesn't have a philosophy about what a window is. You can get support for the various AT&T bit-mapped terminals as an add-on package for S5; those do handle terminals with a mechanism other than pseudo-terminals (the "terminal emulator" window code runs in the terminal itself, so each such window sort of uses a channel provided over a serial link), but I think it has an "ioctl" that's similar to TIOCGWINSZ, named JWINSIZE. ("J" stands for "Jerq", which, as I understand it, was the original name of the BTL Research bit-mapped terminal, before it was named the Blit.) Then again, 4.xBSD doesn't come standard with a window system, either (unless 4.3-tahoe comes standard with X11), so it doesn't really have a philosophy about what a window is, either. If S5R3.2 comes with X11, I suspect it also provides pseudo-ttys and TIOCGWINSZ/TIOCSWINSZ.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/02/88)
In article <6766@spool.cs.wisc.edu> dave@cs.wisc.edu (Dave Cohrs) writes: >There doesn't appear to be such functionality in SystemV (they have >a different philosophy about what a window is, I think). It is true that a layer is rather different from other systems' notions of what a window is, but UNIX System V does have window size information set/get ioctls. See <sys/jioctl.h>. >The TERMCAP variable won't automatically change. It shouldn't. If the terminal handler size information is set, any termcap-using utility should use that information in place of whatever default is provided by the termcap entry for the terminal. Note that for this to work correctly, the termcap entry must not have any wired-in assumptions about window size (for example, "ll" normally has the vertical size wired into it).
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/03/88)
In article <564@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >S5 doesn't come standard with a window system (unless S5R3.2 comes >standard with X11), ... This isn't quite right. UNIX System V release 3 includes a "basic windowing utilities" floppy that the 3B2 user can install or not, but it is at least a standard part of the distribution. This supports the "xt" layer protocols used by the Blit descendants. I don't know what AT&T's future windowing plans are; they've announced (with Sun) a commitment to the "Open Look" but then everybody and his brother is pushing some window interface right now. Too bad if X11 pushes out the in-many-ways-superior layers approach. Layers aren't just pseudo-terminals, they're much more powerful.
bpendlet@esunix.UUCP (Bob Pendleton) (12/03/88)
From article <2081@vedge.UUCP>, by lai@vedge.UUCP (David Lai): > 2 problems: This works under Ultrix and SunOS, you mileage may vary. > 1) How is a program able to tell the size of a pseudoterm's window. This gets it (void) ioctl(0, TIOCGWINSZ, &tty_winsize); This passes it on (void) ioctl(slave_tty, TIOCSWINSZ, &tty_winsize); This passes on the SIGWINCH signal (void) ioctl(slave_tty, TIOCGPGRP, (char *) &pgrp); (void) killpg(pgrp, SIGWINCH); > Is there a termcap entry which specifies that the screen can be > resized? (The termcap man pages dont mention it). I couldn't find one. Anyone knows, I'd like to see it. > How does a program > get 'signalled' when a resize occurs (ie. like vi doing a redraw after > a resize) ? SIGWINCH. catch it using something like (void) signal(SIGWINCH, change_window); Where change_window is a procedure that tells you about it. > > 2) How can the termcap be modified automatically when a 'resize' occurs, when > not in a program (ie at the shell prompt)? This would be useful so that > the next 'ls' or other such commands would output an appropriate number > of columns. You could fake a new termcap as a variable in the environment that gives the current size of the window. But, if the shell doesn't pass it along you will never see it. One trouble is that csh, at least the one I'm using under SunOS, doesn't pass on SIGWINCH, and doesn't do anything with it. So if you are running under csh, you can't get it so you can't do anything with it. to get around this I run emacs directly under an xterm. And some day I'll get things fixed so I can run emacs directly as an X application and throw away xterm. > > I am looking for a general case solution which should be able to be > applied to various windowing systems. Does this involve a special > tty/pty driver? No, the existing one seem to work just fine. But figuring out how to use it is another story. :-) Reading xterm, ile, or rlogin might help you understand it better. Study the pty/tty driver and SIGWINCH, the information you need is all there, it's just well hidden. I hope this is useful. Bob P. -- Bob Pendleton, speaking only for myself. UUCP Address: decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet Reality is what you make of it.
guy@auspex.UUCP (Guy Harris) (12/04/88)
>I don't know what AT&T's future windowing plans are; they've announced >(with Sun) a commitment to the "Open Look" but then everybody and his >brother is pushing some window interface right now. Too bad if X11 >pushes out the in-many-ways-superior layers approach. Too bad, then, I guess, because as far as I know AT&T plans to go with X11 or X11/NeWS; they're doing the Xt-based implementation of the Open Look interface. What do you mean by "the ... layers approach"? 1) The notion of a windowing terminal? People are already building terminals with X11 in them, so if you don't like the idea of having the computer on which you run your programs also painting bits on the screen, X11 doesn't force you to accept that idea. (I presume you can, under layers, somehow arrange to run a program on a machine other than the one to which your layers terminal is connected and have it interact with layers just as if it were running on that machine; if not, X11 does a *better* job than layers does in that instance.) 2) The ability to run some of your window system in the terminal, including downloaded user-interface code? You can do that with NeWS, assuming you're willing to write the downloaded code in PostScript (or have some translator that will generate PostScript for you - is there a tool that will do that for you?). You could also arrange to do something like that on at least some boxes that run X11, probably, via the extensions mechanism, assuming you had some way of downloading code to implement the extension. 3) Some aspect of the user interface of the window system provided by layers? X11 doesn't dictate much of the user interface; you might well be able to implement the layers user interface atop X11. >Layers aren't just pseudo-terminals, they're much more powerful. Oh, really? Can I use layers to implement, say, 4.xBSD's "script"? I'm not sure layers and pseudo-ttys are the same sort of beast, so I'm not sure you can say that one is "more powerful" than the other.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/05/88)
In article <577@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >(I presume you can, under layers, somehow arrange to run a program on >a machine other than the one to which your layers terminal is connected >and have it interact with layers just as if it were running on that >machine; if not, X11 does a *better* job than layers does in that >instance.) Sure; we routinely use "sam" with the interactive part running in the terminal and the host file management part running on a system two hops away. The important point is that the layer system does not have to be aware of networking; the host part is run via rexec or equivalent. In fact "sam" runs on SunOS the same way. A better job can be done with streams, but we don't have them on our BSD-based systems, alas. >The ability to run some of your window system in the terminal, >including downloaded user-interface code? You can do that with NeWS, >assuming you're willing to write the downloaded code in PostScript Layers terminal code is written in C, which makes it much more convenient since most of our useful application libraries are in C already and we don't have to retrain our programmers. In fact, user interaction is ALWAYS controlled in layers by code running in the terminal (either a terminal emulator or some more interesting application). This makes it easy to implement text manipulation between layers, for example. The layer process can cooperate with a host system process if necessary, but normally interactive work does not put the host in the loop. Thus, layers applications are entirely usable on a 5620 or 630 terminal at home over 1200bps dialup. I don't know of anyone who has tried to operate X11 like that. >Some aspect of the user interface of the window system provided by >layers? Layers (xt)-supporting terminals don't dictate "appearance" features, although the built-in firmware does encourage a much cleaner display than other windowing systems. They do provide high-performance interactive support and non-preemptive real-time task scheduling. Their graphics primitives are much simpler and more convenient than anything else I've yet seen, including Sun's and Apple's programming support systems. I merged somebody's X11 port of "sam" in with the others, and at least that usage of the X11 interface is also pretty ugly by comparison. I think all these window system designers went to the same Macintosh school of window programming. >>Layers aren't just pseudo-terminals, they're much more powerful. >Oh, really? Can I use layers to implement, say, 4.xBSD's "script"? You can use xt/layers to do that, though it would be perverse. >I'm not sure layers and pseudo-ttys are the same sort of beast, so I'm >not sure you can say that one is "more powerful" than the other. All a pty is is a full-duplex stream with a terminal handler stuck into it. (Actually, 4BSD ptys aren't quite that.) A layer is one of a set of multiplexed streams on a single transmission channel with reliable data transfer protocol and an intelligent process at each end. This is not as general as a simple pty but it has more inherent power. You could add stuff onto a pty to bring it up to xt layer functionality, except for the multiplexing, which systems without xt or streams multiplexors cannot do very efficiently. (The context- switch overhead to multiplex in user mode on BSD systems is horrendous. We do it anyway because layers is so useful that even an emulation is better than not having it.) The only thing X11 seems to have going for it is a variety of vendors supporting it. That is probably sufficient for it to take over the market, just as NFS did despite its technical flaws. As I said, it's a pity. I hate the bandwagon effect..
les@chinet.chi.il.us (Leslie Mikesell) (12/06/88)
In article <9065@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >The only thing X11 seems to have going for it is a variety of vendors >supporting it. That is probably sufficient for it to take over the >market, just as NFS did despite its technical flaws. As I said, it's >a pity. I hate the bandwagon effect.. If AT&T really wanted people to use layers (and buy their terminals that know about them) they might try supplying an emulator for a layering terminal as a standard part of the 6386 SysVr3 that would run on the console. Les Mikesell
friedl@vsi.COM (Stephen J. Friedl) (12/06/88)
In article <577@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: > I'm not sure layers and pseudo-ttys are the same sort of beast, so I'm > not sure you can say that one is "more powerful" than the other. No no no no. Layers are like BSD job control :-) :-) :-) :-) :-) Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl Nancy Reagan on my new '89 Mustang GT Convertible: "Just say WOW!"
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (12/06/88)
In article <9042@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >It is true that a layer is rather different from other systems' notions >of what a window is, but UNIX System V does have window size information >set/get ioctls. See <sys/jioctl.h>. You seem to be implying that the layers/xt system is an integral part of System V or the SysV tty interface. I don't think this is the case. Do you think that a windowing system running on SysVr3 should support the layers/xt ioctl for window size? (I don't mean whether it should allow such a function, just whether it should use the same ioctl command code and return the same data structure.) This question has come up with regard to Commodore's proprietary windowing system for Amiga Unix (SysVr3); comments are welcome. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (12/06/88)
In article <577@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: > (I presume you can, under layers, somehow arrange > to run a program on a machine other than the one to which > your layers terminal is connected and have it interact > with layers just as if it were running on that machine; if > not, X11 does a *better* job than layers does in that > instance.) I disagree. An X11 application can not do its display on a machine to which it is not connected, either; I think your complaint about layers is more about the fact that layers is usually run over a direct serial link, and X is usually run over a (multiple-machine) network. Both systems require a virtual 8-bit flow-controlled data path between the display server and the application, and I think they are very similar in that respect. I think the layers protocol is a bit intertwined with the underlying "xt" protocol, so it may have a slight deficiency there (experts, please correct as needed). -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
guy@auspex.UUCP (Guy Harris) (12/07/88)
>Do you think that a windowing system running on SysVr3 should support >the layers/xt ioctl for window size? (I don't mean whether it should >allow such a function, I presume you realize that if it supports more than one size of "tty window" (i.e., window in which you can run a program that wants to talk to a "dumb" terminal), it should allow such a function. >just whether it should use the same ioctl command code and return the >same data structure.) I think future S5 releases will have TIOCGWINSZ, 4.3BSD-style; you should probably consider supporting both.
guy@auspex.UUCP (Guy Harris) (12/07/88)
>I disagree. An X11 application can not do its display on a machine >to which it is not connected, either; I think your complaint about >layers is more about the fact that layers is usually run over a >direct serial link, and X is usually run over a (multiple-machine) >network. Err, umm, layers can be run on a terminal attached to a machine that is, in turn, attached to "a (multiple-machine) network", as well; the question is whether programs on other machines on the network can use that terminal in the same way that programs on that machine can, in the same way programs using X can run either on the machine on which the display server is running (assuming it's not just an "X terminal" not set up to run applications) or on any machine that can be *logically* connected, via some kind of network connection, to that machine. If the answer is "no", then X11 *does* do a better job; however, Doug's answer seems to be "yes, programs on other machines can do that".
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/07/88)
In article <7082@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
-If AT&T really wanted people to use layers (and buy their terminals that
-know about them) they might try supplying an emulator for a layering
-terminal as a standard part of the 6386 SysVr3 that would run on the
-console.
Particularly since a PC-LAYERS is rumored to have existed for some time now.gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/07/88)
In article <5444@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >Do you think that a windowing system running on SysVr3 should support >the layers/xt ioctl for window size? (I don't mean whether it should >allow such a function, just whether it should use the same ioctl >command code and return the same data structure.) Sure. I emulate the jioctl window size stuff for the System V environment on 4.nBSD using the native TIOC[GS]WINSZ, for example. The numeric ioctl value is not important, but if other software on the system knows about the xt ioctls then you'd need to handle the emulation in the kernel instead of at the program/OS interface level. The really interesting question is, what should sort-of-UNIX-portable source code do to cope with the three major (and several minor) variations on this theme? It's made worse by the inability to test for the presence of header files such as <sys/jioctl.h>.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/07/88)
In article <5445@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >I think the layers protocol is a bit intertwined with the underlying >"xt" protocol, so it may have a slight deficiency there (experts, >please correct as needed). The protocol layers are fairly cleanly separated, but the multiplexing only allows for 8 channels (one of them used for layer system control), which is a definite deficiency.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/07/88)
In article <964@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >No no no no. Layers are like BSD job control :-) :-) :-) :-) :-) Not at all. You must be thinking of so-called "shell layers" based on sxt pseudo-devices. Guy and I were discussing real layers as used on descendants of Rob Pike's Blit terminal (e.g. AT&T 5620, 615, 620, 630).
avr@mtgzz.att.com (a.v.reed) (12/08/88)
In article <5444@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > Do you think that a windowing system running on SysVr3 should support > the layers/xt ioctl for window size? (I don't mean whether it should > allow such a function, just whether it should use the same ioctl > command code and return the same data structure.) Yes, it definitely should. For one thing, the SysVr3 curses library already has code to use these ioctls and their structures when available; by using them, you save yourself the pain of merging the standard curses with something else. For another, I should assume that you will support terminals; someone might wish to use a layers terminal with your machine - and if the ioctls are OK, will be able to just install the layers multiplexed line discipline and run. Adam Reed (avr@mtgzz.ATT.COM)
stox@ttrde.UUCP (Kenneth P. Stox) (12/09/88)
In article <5444@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > In article <9042@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >It is true that a layer is rather different from other systems' notions > >of what a window is, but UNIX System V does have window size information > >set/get ioctls. See <sys/jioctl.h>. > > You seem to be implying that the layers/xt system is an integral part > of System V or the SysV tty interface. I don't think this is the case. Layers/xt is distributed with the UNIX System V.3 sources, I think that qualifies as an integral part of the UNIX Operating System. It is also distributed as a binary on every UNIX System machine AT&T makes, including the 7300/3B1/UNIX-PC. Ken Stox 630 Development Group AT&T B/L SK527-4 att!ttrde!stox
stox@ttrde.UUCP (Kenneth P. Stox) (12/09/88)
In article <964@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: > In article <577@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes: > > I'm not sure layers and pseudo-ttys are the same sort of beast, so I'm > > not sure you can say that one is "more powerful" than the other. > > No no no no. Layers are like BSD job control :-) :-) :-) :-) :-) Well, I guess I see the smiley faces, but layers is nothing like BSD's job control. You may be confusing layers with shell layers which appears similar to BSD job control. Pick up a 630MTG and tell me that layers is in any ways the same as BSD job control. Ken Stox AT&T B/L SK527-4 att!ttrde!stox
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (12/09/88)
In article <594@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: [ about a layers terminal ] > [ ... ] the >question is whether programs on other machines on the network can use >that terminal in the same way that programs on that machine can, in the >same way programs using X can run either on the machine on which the >display server is running (assuming it's not just an "X terminal" not >set up to run applications) or on any machine that can be *logically* >connected, via some kind of network connection, to that machine. The big question is just whether those other machines can establish a logical connection to the layers terminal. The standard layers software doesn't include a TCP gateway or anything like it, so normally, the answer is no. But there isn't anything inherent in the layers spec that prevents such support from being written. I think the "superiority" of X over layers in this respect is entirely due to the transport mechanisms they normally use; the windowing systems themselves are equally suitable for network use. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (12/09/88)
In a previous article <5444@cbmvax.UUCP> I wrote: >Do you think that a windowing system running on SysVr3 should support >the layers/xt ioctl for window size? (I don't mean whether it should >allow such a function, just whether it should use the same ioctl >command code and return the same data structure.) Everyone responding seems to think that a windowing system should support the layers ioctl (JWINSIZE). From a practical standpoint, I agree, but there are a few counter aguments that I will throw out at the world... For example, what about the dependency this introduces on the existence of a device driver in the Unix kernel? If this ioctl is to be the standard means of inquiring window size, then any conforming windowing system *must* have a special device driver installed on the *client* system. What about a windowing system which communicates with its clients with "in band" data, using escape sequences in both directions? Such a system has several disadvantages, but it is also appealing for many reasons, such as its usefulness over a "plain" tty connection or a long stream of virtual connections (like telnet, dataswitches, etc.). It could not support an ioctl of any kind. Also, the idea of display LINES & COLUMNS is not specific to "windowing systems" -- "/dev/console" on the Amiga, for example, is just a plain ANSI text-only terminal, but it might be 80x25, 80x32, 80x50, or 128x100, depending on what kind of monitor and video format are being used, and other factors. I would like to use the same method of inquiring about screen size with this device as with the windowing system. Why should this depend on an ioctl command defined in a header file for a windowing system? In article <9091@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >The really interesting question is, what should sort-of-UNIX-portable >source code do to cope with the three major (and several minor) variations >on this theme? It's made worse by the inability to test for the presence >of header files such as <sys/jioctl.h>. This is more what I was getting at. My complaint is mostly about the idea that one particular implementation be used as a "standard". Kind of like the way Unix system calls are a "standard" way to access files even on non-Unix systems; almost every C compiler for PC OSes provides emulation for open(), read(), etc., even though there was an OS-independent access method documented with almost every Unix system ever distributed. How about a library function to inquire about screen size? Obviously it should be automatically called by curses/terminfo libraries, but in also needs to be available directly. This function would be implemented differently on various systems, hiding the specifics in a library that a portable program could use. The task of window-size- change notification should also be handled. I suppose this is somewhat of a moot point, since even if I wrote this function in the next hour and posted it, it wouldn't become a standard. If submitted to a standards organization, it wouldn't go anywhere for a few years, and in the mean time all the software would have been using JWINSIZE and that would have become the standard. :-) Oh well, maybe I'll feel better now that I've mumbled and complained a bit. Comments, opinions, flames welcome. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
decot@hpisod2.HP.COM (Dave Decot) (12/09/88)
> In article <964@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: > >No no no no. Layers are like BSD job control :-) :-) :-) :-) :-) > > Not at all. You must be thinking of so-called "shell layers" based [boring attempt at mind reading deleted] > Doug Gwyn How many :-)'s *should* Stephen have put on his posting in order for them to be recognizable to your parser? Dave Decot
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/09/88)
In article <5463@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >What about a windowing system which communicates with its clients with >"in band" data, using escape sequences in both directions? Such a >system has several disadvantages, but it is also appealing for many >reasons, such as its usefulness over a "plain" tty connection or a >long stream of virtual connections (like telnet, dataswitches, etc.). >It could not support an ioctl of any kind. Anything that provides "virtual terminals" but no ioctl support is not worth worrying about because nobody in his right mind is going to put up with that when he can easily get real windowing elsewhere. If you use streams-based network technology, you can pass control packets in the nominal data stream. >Also, the idea of display LINES & COLUMNS is not specific to "windowing >systems" -- "/dev/console" on the Amiga, for example, is just a plain >ANSI text-only terminal, but it might be 80x25, 80x32, 80x50, or 128x100, >depending on what kind of monitor and video format are being used, and >other factors. I would like to use the same method of inquiring about >screen size with this device as with the windowing system. Why should >this depend on an ioctl command defined in a header file for a windowing >system? I don't know what you're talking about -- nobody said you should limit your window-size ioctl definitions to <sys/jioctl.h>. In fact I'd hope that <sys/ioctl.h> defines TIOC[GS]WINSZ or equivalent on any modern UNIX. >How about a library function to inquire about screen size? Great, but 1003.1 didn't define one. Nor did the SVID. Where is the "standard" going to come from? Until there's an accepted standard for this, how about adding it to your little box of system interface functions (those things with invariant application interface specs that are implemented differently for different systems).
guy@auspex.UUCP (Guy Harris) (12/10/88)
>The big question is just whether those other machines can establish >a logical connection to the layers terminal. The standard layers >software doesn't include a TCP gateway or anything like it, so normally, >the answer is no. Err, umm, maybe I missed something, but it sure sounded like Doug Gwyn said you could achieve what is really desired here, which is to run a display-oriented program on a machine other than the one to which the tube is directly physically connected, so the answer is, apparently, "yes", not "no". My guess is that the "TCP gateway" in this case is something like "rlogin", passing characters from the network connection to the terminal and *vice versa*. >But there isn't anything inherent in the layers spec >that prevents such support from being written. Now, if you had some terminal-based window system that *didn't* allow that, for whatever reason, the superiority of X over the hypothetical window system in question would be that such support wouldn't *have* to be written for X....
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/10/88)
In article <14020052@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >> In article <964@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >> >No no no no. Layers are like BSD job control :-) :-) :-) :-) :-) >> Not at all. You must be thinking of so-called "shell layers" ... >How many :-)'s *should* Stephen have put on his posting in order for >them to be recognizable to your parser? The problem was, there was no way to tell what he thought was funny about his posting. Perhaps he thought that AT&T's once-heard claim that "shell layers" were functionally equivalent to BSD job control was funny. There is no reason to even think of real layers in conjunction with job control; they're independent of each other (and I use both at the same time). Two of us responded to clarify for those who may have been misled that the "job control" flavor of "layers" (i.e. "shell layers") wasn't what we were talking about. This may have saved somebody some confusion.
muller@sdcc7.ucsd.EDU (Keith Muller) (12/10/88)
As far as I know there are only three ways to create a layer: 1) with the mouse 2) with a host resident "agent" subroutine call 3) from a terminal resident program None of these directly support the X client model where a client is on a remote host and can directly communicate to a X server (e.g. there is not a network version of the openchan() agent library function). It would not be too difficult to add a "netopenchan()" agent library function (at least to the 4.3BSD 630MTG software it can be done). I assume that this would be an attractive feature? Keith Muller University of California
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/11/88)
In article <1107@sdcc7.ucsd.EDU> muller@sdcc7.ucsd.EDU (Keith Muller) writes: >As far as I know there are only three ways to create a layer: > 1) with the mouse > 2) with a host resident "agent" subroutine call > 3) from a terminal resident program Correct. Keith is pretty well informed about this stuff, so much of what I have to say is for the benefit of those who don't know much about layers. >None of these directly support the X client model where a client is on a >remote host and can directly communicate to a X server (e.g. there is not >a network version of the openchan() agent library function). It would not be >too difficult to add a "netopenchan()" agent library function (at least to >the 4.3BSD 630MTG software it can be done). I assume that this would be an >attractive feature? The X client model and layers aren't entirely conformable. (That's what started this discussion!) Personally I think the hostagent feature should work from any host that is being used in the window. For a specific example, consider remote-host use of "sam": human user of DMD/MTG terminal | ^ mouse/keyboard | movements, | | clicks, | | dragging, | | keystrokes | bit-map display v | samterm running in DMD/MTG layer with layersys RTOS support ^ terminal port | special "sam" transaction record protocol v original "sam -r remote_host_name" process on layer host system, now acting just as a "wire". ^ net connection | transparent rexec I/O streams v remote_host "sam -R" process (file editing server) Now, "sam -R" doesn't manipulate windows using the hostagent feature, but suppose it did. The associated ioctls really should be sent to the layer host system (this is one of the things streams are good for). The layer host can take care of the layer manipulation, because it knows how. The remote system need know nothing about layers or xt. You probably have quite a problem getting the Berkeley/Sun network stuff to support this scheme. It should be easy with current UNIX System V. A workaround for use with existing puny network facilities is to have the "sam -R" process communicate its needs to samterm and have samterm communicate with the layer host to keep it apprised of its window manipulations. In fact that's pretty much how existing DMD/MTG software does operate. (The layer host is informed via the control channel on the terminal port, by layersys.)
friedl@vsi.COM (Stephen J. Friedl) (12/18/88)
In article <964@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: > No no no no. Layers are like BSD job control :-) :-) :-) :-) :-) In <unknown article>, Doug says: > Not at all. You must be thinking of so-called "shell layers" ... In article <14020052@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: > How many :-)'s *should* Stephen have put on his posting in order for > them to be recognizable to your parser? Maybe I should add some more. :-) :-) :-) :-) :-) :-) :-) :-) :-) :-( :-) :-) :-) :-) :-) :-) :-) :-) :-) A commonly-asked question from a BSD-kind-of-{guy,gal} is "What's the equivalent of job control?", and the answer is always "shell layers", which uses the SXT mechanism. I feel that this answer is in the spirit of the question even though it's only a very rough analog. *Some* people think that they are the same thing, and that's what my posting was making a poor joke of. Sorry, Doug. Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl Nancy Reagan on my new '89
rbj@nav.icst.nbs.gov (Root Boy Jim) (12/24/88)
? From: Doug Gwyn <gwyn@smoke.brl.mil>
? ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes:
? >How about a library function to inquire about screen size?
? Great, but 1003.1 didn't define one. Nor did the SVID. Where is
? the "standard" going to come from?
How about from us? What did you have in mind? :-)
(Root Boy) Jim Cottrell (301) 975-5688
<rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa>
Crackers and Worms -- Breakfast of Champions!