Re: Gdk unexpected window destruction patch.

[Nat Friedman <nat nat org>]

Hi Tim,

Tim Janik <timj@gtk.org> wrote:
> On 18 Aug 1999, Nat Friedman wrote:
> 
> > 
> >     Problem number two (2) is that the component may have had some
> > drawing queued on one of those now-defunct windows.  And those draw
> > operations will result in BadDrawable X errors, terminating the
> > component.  The source-level disfigurement required to fix this has
> > been relegated to Bonobo, which basically just ignores all BadDrawable
> > X errors for now (see bonobo/gnome-main.c).  Suggestions welcome.
> 
> 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:

    For the record, I have to worry about both BadDrawable and
BadWindow errors.

    Ok, I tried your suggestion, but no luck -- the X errors still
occur most of the time.  It's a real shame to have to ignore these
errors in Bonobo; I can see it leading to serious problems in the
future, and so I'd like to come up with a real solution.  The only
thing that comes to mind right now is a gross hack: when a
BadDrawable/BadWindow error occurs, cache the XID and set a timer.  If
that XID is unexpectedly destroyed before the timer goes off, delete
the timer.  Otherwise, the timer will eventually expire and the error
will be reported.  Actually, would it make sense to do the following:

    When an BadDrawable/BadWindow error occurs, flush the X connection
to get all incoming server messages on the queue.  Then peek through
the queue and see if there are any DestroyNotifys for the relevant
XID.  If so, ignore the X error.

    This would only work, of course, if I could guarantee that the
DestroyNotify is sent out with some degree of synchronicity with
respect to the occurence of the BadDrawable/BadWindow.  And that may
be just flat-out not the case.

> of course gtkplug.c doesn't currently come with an unrealize
> handler, but that is a bug in its own right that has to be fixed.

    Ok, I have fixed this in my local version and will include it in
the next patch (to be sent along as soon as I get online to cvs diff).

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

    Do you mean that widgets should be able to choose not to be
destroyed, just as they can choose not to be deleted?  I'm not sure
that I see the benefit of this at all: a widget gets a chance to deal
with its unexpected destruction in the "destroy_event" callback.  What
more does it need?

> i'm introducing gdk_window_destroy_notify_new() here, in 1.3 we can
> rename that back to gdk_window_destroy_notify() then.

    Good point.  I've incorporated this suggestion.

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

    I would like to leave the warning in.  The unexpected destruction
of a window should never be a normal occurence in Bonobo, but what
Bonobo does require is that unexpected window destruction not affect
the robustness of the component.  So it's still an unusual and
noteworthy thing for a window to be destroyed unexpectedly, and the
louder the component is about it, the more likely someone will
actually bother to track down the responsible container bug.

> and actually invoke gdk_window_internal_destroy (window, FALSE,
> FALSE) here as well?  especially since Gdk will then discard further
> operations on then window as well (we got checks all over the place
> for window_private->destroyed).

    You're probably right; I think I do need to invoke
gdk_window_internal_destroy() here.  Fixed locally.  Thanks so much
for all your suggestions Tim!

Best,
Nat