Re: Gdk unexpected window destruction patch.

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> > >     case GDK_DESTROY:
> > >       gtk_widget_ref (event_widget);
> > >       gtk_widget_event (event_widget, event);
> > >       if (!GTK_OBJECT_DESTROYED (event_widget))
> > >         gtk_widget_destroy (event_widget);
> > >       gtk_widget_unref (event_widget);
> > >       break;
> > > 
> > > in a way that GDK_DESTROY behaves exactly like GDK_DELETE, so components can
> > > have a means to recover by returning TRUE from destroy_event, though
> > > that would change existing behaviour i doubt, tehre's actually code out there
> > > taht would trigger this (and then again, i've never been much in favour of
> > > that unconditioned widget destruction).
> > 
> > There is no way an application is going to recover and
> > prevent a window from being destroyed once it receives a GDK_DESTROY
> > on a window. It is already gone, kablooey, kaput. 
> 
> i'm not saying that the app can prevent the window from being destroyed,
> but i see no good reason to not let the app handle that case *if it wants
> to*. note, that without any further signal connections, the changes will
> still cause the widget to be destroyed.

So you are saying that the application can 

 1) not connect handlers and have GTK+ destroy the heirarchy
 2) Connect handlers, return FALSE, and have GTK+ destroy
    the hierarchy.
 3) Connect handlers, destroy the hierarchy and return TRUE. 
 4) Connect handlers, not detsroy the hierarchy (which would
    be a BUG)

1), and 2) were possible before, 3) isn't really any
different from 2), and 4) isn't useful.

I'm not totally opposed to this change - it would be
slightly more consitent, but you are giving the 
application more rope to hang themselves with without
really giving them any more capabilities.

Regards,
                                   Owen