home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / windows / x / 14613 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  2.4 KB

  1. Path: sparky!uunet!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.windows.x
  4. Subject: Re: Kills from Window Manager
  5. Date: 30 Jul 1992 07:03:45 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 36
  8. Message-ID: <15848hINNalt@early-bird.think.com>
  9. References: <1460adINN77b@early-bird.think.com> <14ptagINNrdo@early-bird.think.com> <1992Jul30.004540.7641@thunder.mcrcim.mcgill.edu>
  10. NNTP-Posting-Host: gandalf.think.com
  11.  
  12. In article <1992Jul30.004540.7641@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
  13. >An application that does multiple top-level windows but
  14. >still doesn't do WM_DELETE_WINDOW is IMO broken badly enough that I'm
  15. >willing to ignore its existence.)
  16.  
  17. I guess this is where we differ.  I believe WM_DELETE_WINDOW was introduced
  18. in X11R4.  R4 and R5 servers and window managers are supposed to be upward
  19. compatible with R3 clients.  There are probably many applications that
  20. haven't been significantly enhanced since then (they may have been
  21. recompiled with the R4 or R5 libraries if you're lucky).  I don't think
  22. that these are "broken badly", they're just slightly out of date.
  23.  
  24. Nowhere in the ICCCM does it say that multi-window clients must implement
  25. WM_DELETE_WINDOW.  It seemed to be an optional protocol to me.  It's
  26. certainly a good idea, but if an application provides other mechanisms to
  27. delete windows then it isn't required.
  28.  
  29. And even if applications that *should* do WM_DELETE_WINDOW but don't are
  30. broken, I don't feel that it's such a serious bug in the application that
  31. they deserve to crash.  If the user performs an operation that is
  32. documented as deleting a single window, and it causes the application to
  33. die, that's not a Good Thing.  While we can argue that it's the application
  34. developer's mistake, the WM designer certainly isn't helping matters by
  35. performing an XKillClient() when a WM_DELETE_WINDOW was intended.  It's
  36. poor human factors to expand the effect of a request in that manner.
  37.  
  38. A reasonable compromise could be for the WM manager to try
  39. WM_DELETE_WINDOW.  If it fails, it could put up an alert "Couldn't delete
  40. the specified window.  Should the entire client be killed?"  This is
  41. analogous to the "Do you really want to exit?" alert that many applications
  42. produce when you try to delete their main window.
  43. -- 
  44. Barry Margolin
  45. System Manager, Thinking Machines Corp.
  46.  
  47. barmar@think.com          {uunet,harvard}!think!barmar
  48.