Re: Gdk unexpected window destruction patch.

[Tim Janik <timj gtk org>]

On 20 Aug 1999, Owen Taylor wrote:

> > hm, i'm not at all sure about this, but i'd actually imagine that your
> > BadDrawable X errors could be fixed by adding a GtkPlug.destroy_event
> > handler:
> 
> No, the BadDrawable errors may and will occur before the
> DestroyNotify is received.

hum, well, then the error handler is still required, but that doesn't
neccessarily mean there'd be no point in a destroy_event handler and
plug unrealization.

> > and eventhough that is not vital for your case, this code portion in
> > gtkmain.c should also be adapted:
> >     case GDK_DELETE:
> >       gtk_widget_ref (event_widget);
> >       if (!gtk_widget_event (event_widget, event) &&
> >           !GTK_OBJECT_DESTROYED (event_widget))
> >         gtk_widget_destroy (event_widget);
> >       gtk_widget_unref (event_widget);
> >       break;
> > 
> >     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.


> The best thing to do at this point is to destroy the
> widget heirarchy and hope that cleans up things OK.
> I suppose we could just unrealize, and not destroy,
> but that would mean unconditionally setting the toplevel
> !VISIBLE which is also yucky.

that's exactly the opportunity i'd like to give to the application,
but as long as GDK_DESTROY destroyes the widget heirarchy unconditionally,
it can't do anything at all.

> 
> > void
> > gdk_window_destroy_notify_new (GdkWindow *window,
> >                                GdkEvent  *event)
> > >  {
> > >    GdkWindowPrivate *private;
> > >    
> > > @@ -701,8 +701,33 @@
> > >      {
> > >        if (private->window_type == GDK_WINDOW_FOREIGN)
> > > 	gdk_window_internal_destroy (window, FALSE, FALSE);
> > > -      else
> > > +      else {
> > > +	GdkWindowPrivate *parent;
> > > +
> > > 	g_warning ("GdkWindow %#lx unexpectedly destroyed", private->xwindow);
> > 
> > hm since this will become a valid code path for bonobo then, wouldn't it make
> > sense to actually take that warning out (it could be left as a debug option
> > though) and actually invoke gdk_window_internal_destroy (window, FALSE, FALSE)
> > here as well? especially since Gdk will then discard further operations on the
> > window as well (we got checks all over the place for window_private->destroyed).
> > owen?
> 
> This is not a valid code path. It means that the socket has
> unexpectedly crashed. Nat's patch does not make that safe,
> it just makes it work a lot more of the time. I think 
> a warning is appropriate here.

well ok, but shouldn't we still destroy the window here, in case an
app wants to recover (or simply shutdown properly) and needs
window_private->destroyed==TRUE?

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ