Re: close -> destroy

[Owen Taylor <otaylor redhat com>]

john@synergy.caltech.edu writes:

> Perhaps it might be a good idea to change this default behavior, for a couple
> reasons, 
 
> 	1. It seems very uncommon that the default close behavior wil
> lbe used, and even when it is, a signal handler is still used alot
> of the time to do some other random stuff and could just as easily
> destroy the widget itself..
 
Actually, we changed the behavior to the current one about
a year ago; before we made the change there were a _lot_
of broken programs that did absolutely nothing on WM close.

That wasn't really the whole reason we made the change - 
there were some technical reasons dealing with event propagation
why the TRUE == handled meaning was more natural, if I
recall correctly; but I think, on the whole, programs
get it right more currently than they did then.

At this point, changing it a again is in any case completely
impossible.

> 	The other, more compelling reason, is that it is a "Window
> Manager Optional" protocol, meaning that if someone does all their
> development with a window manager that doest supoort it, suddenly
> their program behaves very strangely on other systems due to the
> drastic defaults. for just the case of window_delete this isnt that
> bad, since most people understand/use a window manger that supoortes
> it, but in the future once more and different "Window Manager
> Optional" protocols are supported, if we continue to create drastic
> defaults (such as this one.) suddenly old programs are broken due to
> a WM update, if new protocols are by default ignored then it is
> inconsistant with the window_delete signal... just something to
> think about... its not that vital but i thought id mention it for
> the sake of design cleanliness...

If a window mananger does not support WM_DELETE then closing
the window through a window manager will kill the application
in such a way that there is absolutely no way to recover.
So, luckily, all WM's that I know of support WM_DELETE.
It isn't optional in any meaningful way.

I somehow suspect that if there are  new optional protocols
they will be handling completely different things, so 
the issues will be very different, but your point is well
taken.
                                        Owen