home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0050.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.9 KB
  1. From: guy@sun.com (Guy Harris)
  2. Date: Sat, 11 Oct 86 03:05:09 PDT
  3.  
  4. > (1) True windows, such as a 5620, Sun, UNIX PC, etc.  Each window
  5. > acts like a terminal.  This is unquestionably the best, but it
  6. > requires special hardware, and is an area that needs to be
  7. > standardized.
  8.  
  9. At some point, perhaps.  It's unclear whether now is the time to do so.  I
  10. don't think window systems have been around long enough that people can say
  11. "this is how to do a window system".  I don't think window systems have
  12. settled down enough to start standardizing yet.  (How many people would have
  13. thought of using PostScript as a rendering language for a window system, and
  14. extending it to handle input events as well and act as an extension
  15. language, before James Gosling first talked about his work?  Would people
  16. have missed that entirely when developing a standard?)
  17.  
  18. Also, what would the standard specify?  A C-language binding to routines to
  19. manipulate the screen?  A set of low-level operations to render images
  20. within a window, a high-level user interface toolkit, something in between,
  21. all of the above, or none of the above?
  22.  
  23. > (3) Berkeley job control.  Henry may think this is ugly, but from a user's
  24. > point of view, if you can't have a real bitmapped display, this is the
  25. > next best thing.  I strongly prefer it to (2).
  26.  
  27. For what it's worth, I will point out that even though I have access to (1),
  28. I still use (3).  I haven't analyzed my use of it enough to really say why.
  29. Some of it may be that it takes a while to pop up a new shell window in my
  30. environment (time to start the window process that provides the simulated
  31. terminal and time to start up the Korn shell).  Some of it may be that the
  32. EMACS key bindings I have let me suspend EMACS but not easily fork off a new
  33. shell.  Some of it may be that it is occasionally convenient to move a job
  34. into the background when you discover it'll take a while to complete, or
  35. move a backgrounded job into the foreground to abort it.
  36.  
  37. > I do think that certain things should be standardized:
  38.  
  39. > (a) termio, or at least the subset that's commonly used.
  40.  
  41. The current proposal before 1003.1 does this; it fixes some botches in
  42. "termio" as it exists (MIN and TIME are not overloaded with EOF and EOL, for
  43. instance) and restores a couple of capabilities deleted when the System III
  44. terminal driver first appeared.
  45.  
  46. > (b) an ioctl to find out the current window size, in chars and pixels.
  47.  
  48. The current proposal has this, but does not give the window size in pixels.
  49. The "termio" interface is really not a good portable interface for doing
  50. graphics, since most terminals can't do graphics.  As such, it's not clear
  51. why the window size in pixels should be provided by this interface.  A
  52. program that really cares how big the window is in pixels should probably
  53. use the local window system primitives for this, since it has to use the
  54. window system's rendering primitives to draw things anyway.
  55.  
  56. Volume-Number: Volume 7, Number 51
  57.  
  58.