home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0054.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.9 KB
  1. From: cbosgd!cbosgd.ATT.COM!mark@seismo.css.gov (Mark Horton)
  2. Date: Sun, 12 Oct 86 23:50:46 edt
  3. Organization: AT&T Medical Information Systems, Columbus
  4.  
  5. The virtual screen stuff, such as UNIX or Xenix on a PC have, should be
  6. considered a poor cousin of a true bitmapped window capability.  Aside
  7. from losing the ability to watch two windows at once, they are essentially
  8. the same.  Both are nice, neither is an alternative for anything except
  9. a personal computer or workstation.
  10.  
  11. By the way, another possibility has been suggested: something like System
  12. V's shell layers, but using scrolling regions in a vt100 or similar terminal
  13. to lock the terminal into the appropriate window.  You lose the ability to
  14. see async updates in another window, and you still need ptys and select,
  15. but you don't need curses, and you shouldn't get the mushy feeling.
  16. Something would have to be done about ^Z not working in raw mode, so you
  17. could break out of an rlogin or cu or vi.  One way to do this would be
  18. something like Berkeley's TIOCSTI, so the program can detect the situation
  19. (using a multi-char escape sequence), take itself out of raw mode, and
  20. type the ^Z itself.
  21.  
  22. (Henry's complaint about user programs having to be modified is a minor
  23. one, in my opinion.  A program that isn't screen oriented needs no
  24. modification.  A program that is screen oriented can use curses, and
  25. curses can catch the signal and redraw the screen as needed.  The only
  26. programs that need modification are those that have to be transparently
  27. able to pass ^Z through, this mostly means remote login programs, and
  28. they need this kind of capability without job control anyway.)
  29.  
  30. >From: guy@sun.com (Guy Harris)
  31. >
  32. >> (1) True windows, such as a 5620, Sun, UNIX PC, etc.  Each window
  33. >> acts like a terminal.  This is unquestionably the best, but it
  34. >> requires special hardware, and is an area that needs to be
  35. >> standardized.
  36. >
  37. >At some point, perhaps.  It's unclear whether now is the time to do so.
  38.  
  39. I did not mean to imply that it should be standardized NOW, although I
  40. think the field is starting to generate enough examples that it would be
  41. worthwhile for someone to start looking at it.  We certainly aren't ready
  42. to put it into P.1003 yet.
  43.  
  44. What I meant is that certain common elements should be standardized,
  45. in particular, the ioctl to get and set the current window size.
  46. These all look the same, but with different particulars.
  47.  
  48. >> (b) an ioctl to find out the current window size, in chars and pixels.
  49. >
  50. >The current proposal has this, but does not give the window size in pixels.
  51. >The "termio" interface is really not a good portable interface for doing
  52. >graphics, since most terminals can't do graphics.  As such, it's not clear
  53. >why the window size in pixels should be provided by this interface.
  54.  
  55. The reason I mention pixels is that many of the existing ioctls seem to
  56. bundle the pixel numbers and char numbers into the same ioctl.  Perhaps
  57. it does make sense to separate them.
  58.  
  59. By the way, I think both "get" and "set" operations should be standardized,
  60. and the standard should state that both ioctls must work on both sides of
  61. the pty.  (This assumes we can appropriately specify what a "pty" is.)
  62.  
  63. The "get" operation can indeed be isolated into tgetnum (termcap) and
  64. setupterm (terminfo.)  But lack of standardization means that the sources
  65. to termcap and terminfo have to be cluttered up with umpteen different
  66. ways to do the same thing.
  67.  
  68. The "set" operation is needed for window managers, and also so there can
  69. be a shell command to set the window size when the system gets it wrong.
  70. (The system gets it wrong a lot in practice, all you have to do is remote
  71. login through a link that doesn't pass the window size, such as cu, telnet,
  72. or 4.2's rlogin.  (4.3 passes the size.))  Sometimes windows get resized,
  73. too, so it would be useful for the cu/rlogin program to be able to send a
  74. shell command through when this happens.)
  75.  
  76.     Mark
  77.  
  78. Volume-Number: Volume 7, Number 55
  79.  
  80.