home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / windows / x / 14632 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  4.6 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!swrinde!sdd.hp.com!elroy.jpl.nasa.gov!mahendo!thyme!kaleb
  2. From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
  3. Newsgroups: comp.windows.x
  4. Subject: Re: Kills from Window Manager
  5. Message-ID: <1992Jul30.172612.24068@thyme.jpl.nasa.gov>
  6. Date: 30 Jul 92 17:26:12 GMT
  7. References: <1992Jul19.104259.6128@pictel.com> <1992Jul24.221634.29882@thyme.jpl.nasa.gov> <1992Jul30.005006.7900@thunder.mcrcim.mcgill.edu>
  8. Organization: Jet Propulsion Laboratory, Pasadena, CA
  9. Lines: 79
  10.  
  11. In article <1992Jul30.005006.7900@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
  12. >In article <1992Jul24.221634.29882@thyme.jpl.nasa.gov>, kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes:
  13. >>In article <1992Jul30.005006.7900@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
  14. > But I
  15. >still contend that not participating in WM_DELETE_WINDOW is not, per
  16. >se, an error!
  17. >
  18. >Could you possibly, then, enlighten us as to just *why* you speak of
  19. >not participating in WM_DELETE_WINDOW as an "error"?  To return to what
  20. >started all this off, given an application that has only one top-level
  21. >window and has no need to clean up after itself when killed (xclock
  22. >makes a good example), I see no reason why it should bother to mess
  23. >with WM_DELETE_WINDOW.  You clearly feel it should, but haven't
  24. >presented any reasons.
  25. >
  26.  
  27. Well Larry, I think this could and should be moved to email, if in fact
  28. it needs to go any further than this.  Keep in mind that I wasn't *trying* 
  29. to be confrontational!  If it came across that way, then I apologize.
  30.  
  31. But, since you asked, here's my *long* treatise on why:
  32.  
  33. First off, I didn't say it's was "...an error."  I implied, by way of an
  34. example, that I thought it was poor style not to participate in WM_PROTOCOLS 
  35. in general, and WM_DELETE_WINDOW in particular.
  36.  
  37. My reasons were and still are:
  38.  
  39. 1.  Small programs have a way of becoming big ones.  If well-behavedness
  40.     (if that's a word) is built in from the beginning, then it doesn't 
  41.     need to be thrown in later.  Citing examples like xclock, and claiming 
  42.     that it doesn't need it, evades the issue.  Even xclock needs it, 
  43.     if only to avoid generating one spurious warning message in error.
  44.  
  45. 2.  Good programs begat good programs.  To paraphrase someone, (sorry, I 
  46.     don't know who said it originally,) we learn to write good programs
  47.     by seeing and copying good programs.  If "good" is defined as being 
  48.     well-behaved, and well-behaved includes participating in WM_DELETE_WINDOW.
  49.     I submit that it does.  Can we agree to disagree?  
  50.  
  51. 3.  When you have two or more ways of handling some occurance and one is 
  52.     superior to another, even if only marginally, why not incorporate the 
  53.     better solution?  You and Ollie have enumerated the number of lines
  54.     of code it takes to implement your respective cases, are you trying to 
  55.     save bytes on a disk?  Do you see something inelegant about partici-
  56.     pating in WM_DELETE_WINDOW?
  57.  
  58. 4.  You, as the X guru, with his own column in The X Journal, should be
  59.     advancing the state of the art of programming in the X Window System.
  60.     Hundreds, if not thousands, of programmers will now have the excuse
  61.     "Larry (der Mouse)" said so..."  Hardly what I'd call setting a good
  62.     example, particularly when you're advocating taking quicky shortcuts
  63.     that are contrary to 1..3 above.
  64.  
  65.     I can't tell you how many programs I've picked up from export:~/contrib 
  66.     that flood my /tmp/xerrors file, because the (dare I say) hacks that 
  67.     wrote them didn't think, or even know, about WM_DELETE_WINDOW.  And I 
  68.     can't help but ask myself, if they didn't know about or think about 
  69.     WM_DELETE_WINDOW, what else didn't they know, or think, about?
  70.  
  71.     And I can imagine a lot of people saying "...who cares about 
  72.     /tmp/xerrors...", and they're right, who cares?  But I think it gets
  73.     down to the philosophical issue of "Why is this program generating an 
  74.     error, which isn't really an error?"  If it were commercial software,
  75.     I wouldn't tolerate it.  If it's one of our deliverables to our
  76.     internal customer (Deep Space Network Operations Control) I won't let
  77.     it out the door like that.  If I were on our Quality Assurance team,
  78.     I wouldn't accept it.
  79.  
  80.     And, having said all of the above, the problem with your solution is
  81.     that while it cures the single erroneous error, it also defeats the
  82.     the reporting of other, real errors in the same "swell foop", which
  83.     is why I said, "IMHO, programs that don't participate..."
  84.  
  85. -- 
  86.  
  87. Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov
  88.  
  89. Not authorized, in any way, shape, or form, to speak for anyone.
  90.