Re: [gtk-list] Re: How can i trap the Close Event

[Raph Levien <raph acm org>]

On Wed, 2 Jul 1997, Otto Hammersmith wrote:

> > I haven't checked through the signal code to make sure that the 
> > gtk_widget_event will reliably return a FALSE in the case that there is 
> > no handler for the delete_event signal, but it seems like a good bet.

Just a quick note: I did check - return_val is set to FALSE in
gtk_widget_event in gtk+/gtk/gtkwidget.c. 

> > Raph
> 
> Hrmph?
> 
> Maybe I'm misunderstanding, but I think you're talking about the
> window manager telling a window to close itself, right?

Yep, that's exactly what I'm talking about.

> That's easy enough to catch... just attach a function to the "destroy"
> signal of the main window.  testgtk does it, does it not?  At least, to
> call gtk_exit to exit cleanly, rather than haning around for no good
> reason. 

Not quite. What happens in GTK now is that the window manager signal is 
turned into a GDK_DELETE event in gdk_event_translate in gtk+/gdk/gdk.c. 
This event comes into gtk_main_iteration in gtkmain.c, where it gets 
handled in a switch statement by a gtk_widget_event () call followed by a 
gtk_widget_destroy () call. The latter call will invoke any signal 
handlers attached to the destroy signal, including the clean exit handler 
you're imagining is in testgtk.c (in fact, such a clean exit handler is 
_not_ present in testgtk.c - the hello example on my Web page is IMHO the 
best way to handle window close events in a way friendly to window 
managers).

The problem with all this is that the window inevitably gets destroyed. 
Thus, you can't make the window manager delete signal cause a dialog box 
to pop up and say "file xxx is unsaved: cancel, save, or quit" instead of 
destroying the window. My proposed patch would allow that - hang a 
handler off the delete signal which pops up the dialog, then returns TRUE 
to prevent the window from actualy being destroyed.

It seems to me from looking at the code that this type of behavior is 
what S&P originally intended (see comment on line 1851 in gdk.c), but 
never actually got around to implementing.

Hope this clears things up.

Raph