From: kaleb@thyme.jpl.nasa.gov (Kaleb Keithley)
Newsgroups: fj.mail-lists.x-window
Subject: Re: Kills from Window Manager
Date: 31 Jul 92 04:44:39 GMT
Distribution: fj
Organization: Jet Propulsion Laboratory, Pasadena, CA

Date: Thu, 30 Jul 92 17:26:12 GMT
Message-Id: <1992Jul30.172612.24068@thyme.jpl.nasa.gov>
Newsgroups: comp.windows.x

In article <1992Jul30.005006.7900@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>In article <1992Jul24.221634.29882@thyme.jpl.nasa.gov>, kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes:
>>In article <1992Jul30.005006.7900@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
> But I
>still contend that not participating in WM_DELETE_WINDOW is not, per
>se, an error!
>
>Could you possibly, then, enlighten us as to just *why* you speak of
>not participating in WM_DELETE_WINDOW as an "error"?  To return to what
>started all this off, given an application that has only one top-level
>window and has no need to clean up after itself when killed (xclock
>makes a good example), I see no reason why it should bother to mess
>with WM_DELETE_WINDOW.  You clearly feel it should, but haven't
>presented any reasons.
>

Well Larry, I think this could and should be moved to email, if in fact
it needs to go any further than this.  Keep in mind that I wasn't *trying* 
to be confrontational!  If it came across that way, then I apologize.

But, since you asked, here's my *long* treatise on why:

First off, I didn't say it's was "...an error."  I implied, by way of an
example, that I thought it was poor style not to participate in WM_PROTOCOLS 
in general, and WM_DELETE_WINDOW in particular.

My reasons were and still are:

1.  Small programs have a way of becoming big ones.  If well-behavedness
    (if that's a word) is built in from the beginning, then it doesn't 
    need to be thrown in later.  Citing examples like xclock, and claiming 
    that it doesn't need it, evades the issue.  Even xclock needs it, 
    if only to avoid generating one spurious warning message in error.

2.  Good programs begat good programs.  To paraphrase someone, (sorry, I 
    don't know who said it originally,) we learn to write good programs
    by seeing and copying good programs.  If "good" is defined as being 
    well-behaved, and well-behaved includes participating in WM_DELETE_WINDOW.
    I submit that it does.  Can we agree to disagree?  

3.  When you have two or more ways of handling some occurance and one is 
    superior to another, even if only marginally, why not incorporate the 
    better solution?  You and Ollie have enumerated the number of lines
    of code it takes to implement your respective cases, are you trying to 
    save bytes on a disk?  Do you see something inelegant about partici-
    pating in WM_DELETE_WINDOW?

4.  You, as the X guru, with his own column in The X Journal, should be
    advancing the state of the art of programming in the X Window System.
    Hundreds, if not thousands, of programmers will now have the excuse
    "Larry (der Mouse)" said so..."  Hardly what I'd call setting a good
    example, particularly when you're advocating taking quicky shortcuts
    that are contrary to 1..3 above.

    I can't tell you how many programs I've picked up from export:~/contrib 
    that flood my /tmp/xerrors file, because the (dare I say) hacks that 
    wrote them didn't think, or even know, about WM_DELETE_WINDOW.  And I 
    can't help but ask myself, if they didn't know about or think about 
    WM_DELETE_WINDOW, what else didn't they know, or think, about?

    And I can imagine a lot of people saying "...who cares about 
    /tmp/xerrors...", and they're right, who cares?  But I think it gets
    down to the philosophical issue of "Why is this program generating an 
    error, which isn't really an error?"  If it were commercial software,
    I wouldn't tolerate it.  If it's one of our deliverables to our
    internal customer (Deep Space Network Operations Control) I won't let
    it out the door like that.  If I were on our Quality Assurance team,
    I wouldn't accept it.

    And, having said all of the above, the problem with your solution is
    that while it cures the single erroneous error, it also defeats the
    the reporting of other, real errors in the same "swell foop", which
    is why I said, "IMHO, programs that don't participate..."

-- 

Kaleb Keithley                          kaleb@thyme.jpl.nasa.gov

Not authorized, in any way, shape, or form, to speak for anyone.