home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / windows / x / 14329 < prev    next >
Encoding:
Text File  |  1992-07-24  |  5.1 KB  |  110 lines

  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!era!feit
  3. From: feit@ERA.COM (Mark Feit)
  4. Subject: X: User simplicity vs code complexity
  5. Message-ID: <1992Jul24.145008.1028@ERA.COM>
  6. Sender: feit@ERA.COM (Mark Feit)
  7. Organization: Engineering Research Associates, Vienna, VA
  8. Date: Fri, 24 Jul 1992 14:50:08 GMT
  9. Lines: 99
  10.  
  11. On comp.windows.x, tpaquette@ita.lgc.com (Trevor Paquette) posts:
  12.  > I was talking to a cohort at work and we got to the subject of X and
  13.  > how many lines of code it takes to do things in X etc..  I came up
  14.  > with "X is the perfect example of User simplicity is directly
  15.  > proportional to code complexity." Do you agree/disagree with this
  16.  > statement and why?
  17.  
  18. Gawd, this discussion seems to come up once every three or four
  19. months.  FAQ #294: "Why is X so complex?"
  20.  
  21. I agree that making the user's life easier requires greater complexity
  22. of code, but X is by no means the culprit.  All of the extra functions
  23. need to have code behind them, and it doesn't matter if you're writing
  24. programs to run under X or on a Teletype Model 33.  That VCR with
  25. on-screen programming you bought last month makes it considerably
  26. easier to tape something than early models, but you can bet your
  27. bottom dollar the innards of the new one are more complex.  Like your
  28. application, SOMEBODY had to sit down and build it.
  29.  
  30.  > To open up a window, create a button, attach a callback to that button
  31.  > when pushed, released and held, while tracking the mouse, takes up a
  32.  > alot of lines of code. (Granted that will take alot of lines in any
  33.  > GFX system but most likely more in X then any other)
  34.  
  35. That's true, but your example isn't a good one.  A few lines from Mark
  36. Langley's editorial aside in O'Reilly volume 4 say it better than I
  37. can (posted without permission):
  38.  
  39.     "You've just seen an X Toolkit equivalent to `hello world,'
  40.     and it is nearly 30 lines long.  But it is node-indepednent,
  41.     does device-independent graphics and can be customized by the
  42.     user to control what font to use, and what colors to use for
  43.     the border, background and text. ... Most people write
  44.     complicated applications, not trivial programs like `hello
  45.     world,' and it is the ease with which a complicated program
  46.     can be written that is the true test of a language."
  47.  
  48. Langley goes on to mention that a basic text editor with some of the
  49. same features of `hello world' (device-independence, user
  50. customization, etc.) can be put together in under 200 lines using the
  51. X Toolkit and the Athena Widget set.  In that you have a program
  52. that's more complex by at least an order of magnitude with less than
  53. that much in increased code.  Is the toolkit's complexity worth being
  54. able to plunk a full-blown text editor into an application with
  55. minimal effort?  You betcha.
  56.  
  57.  > To know X and all the in/outs of it takes about 8 700 page manuals
  58.  > (O'Reilly & Associate) to learn.
  59.  
  60. The only thing that really is "X" (IMHO) is the way the server should
  61. be expected to behave and the protocol that clients use to talk to it.
  62. Everything else was written for the sake of utility, and there's
  63. nothing that prevents you from writing your own low-level library and
  64. toolkits to sit on top of it.  You can really shave those 8 O'Reilly
  65. books down to volumes 2 and 5 plus an extra for any widget set you're
  66. using (i.e., Motif or OpenLook).
  67.  
  68. I don't really see any need to devote my life to learning "all the ins
  69. and outs," because there's simply too much there.  There are things I
  70. know exist but rarely use, and when I use them I dig out the book and
  71. refresh my memory.
  72.  
  73.  > Is there ANYONE out there who knows EVERYTHING in these manuals?
  74.  
  75. Aside from the people who wrote them, I'll second the vote for der
  76. Mouse, but I suspect that like the rest of us, if he doesn't remember
  77. something he looks it up.
  78.  
  79.  > There are many calls
  80.  > that do basically the same thing (XAllocColor vs XAllocColorCells).
  81.  
  82. Yes, and there are reasons for things like that.  Those two particular
  83. functions serve different purposes, and a thorough reading of the
  84. manual pages for both will reveal that.  The reason for most of the
  85. other function pairs (i.e., XDrawLine/XDrawLines) is to keep traffic
  86. between the client and server to a minimum.  The former is for those
  87. cases where you only need ONE.
  88.  
  89.  > How big is X going to get? When will it stop getting bigger? Who
  90.  > created this monster in the first place? Oh well.. back to those
  91.  > manuals..
  92.  
  93. X will get as big as people need it to be.  Yes, there are some things
  94. that could probably have been done better, but for the most part Xlib
  95. and the toolkits (what I presume you're complaining about) are fairly
  96. well-organized.  The complexity is there for those who need the extra
  97. horsepower, and there is a (sometimes steep) learning curve.  Once you
  98. get over the curve, though, you more than recoup the time spent
  99. learning in time saved while building your applications.
  100.  
  101.                         - Mark
  102.  
  103.  ................................. .................................
  104. : Mark A. Feit, Software Engineer : Internet: feit@era.com          :
  105. : Engineering Research Associates : USENET: ...!uunet!era!feit      :
  106.  ................................. .................................
  107.  "Software development is 10% science, 25% ingenuity and 65% getting
  108.            the ingenuity to work with the science."
  109.  
  110.