Re: Gdk unexpected window destruction patch.

[Nat Friedman <nat nat org>]

Tim Janik <timj@gtk.org> wrote:
> > 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.

    The plug unrealization makes sense, but I don't see the use of an
the destroy_event handler.  Leaving the
trap_error_push/flush/trap_error_pop code in would just be misleading,
at best.  I'd rather be honest about having no real solution than
patching in a half solution.

> 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*.

    The app can still handle the event.  Bonobo connects to the
destroy_event signal on the plug and does its cleanup there.

> 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.

    Why can't it?  There's nothing preventing you from connecting some
signal handlers and cleaning up when your widget is unexpectedly
destroyed.  The fact that the widget hierarchy disappears behind you
is the only issue you're questioning, no?


> 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?

    Yes, absolutely.  As soon as I can cvs diff I will post my new
patch.


Thanks for all the discussion, guys.

Regards,
Nat