Re: Gtk+ signal bug
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list redhat com
- Cc: kenelson teal ece ucdavis edu, Tim Janik <timj gtk org>
- Subject: Re: Gtk+ signal bug
- Date: 25 Mar 2000 14:10:45 -0500
The correct fix is really simple, in gtk_signal_handlers_destroy:
if (handler->id > 0)
gtk_signal_handler_unref (handler, object);
should be:
if (handler->id > 0)
{
handler->id = 0;
gtk_signal_handler_unref (handler, object);
}
[ There are two of these ]
But since I would not like to see gtk-- depend on a new release
of GTK+, let me suggest a simple workaround:
All signal handlers are disconnected at destruction, so simply
check
GTK_OBJECT_DESTROYED (obj)
when you are cleaning up after your proxy object, and skip
the disconnection step in that case.
[ The destroyed will probably go away in GTK+-1.4, but this
should work fine for now ]
(In fact, for non-pathological cases, the explicit disconnections
are unnecessary, since for unmanaged gtk-- objects, the GTK+ widget
will be destroyed when the proxy is deleted, and for managed
objects, the proxy object will not be deleted until the GTK+
widget is finalized, which occurs after destruction.)
> Possible solutions.
> 1) The handler could have a flag to indicate that it is already orphaned
> by the object and thus ignores the disconnect.
> 2) The object could remove referenced to the handlers it is abandoning.
> 3) When the object destroys, but the ref counter is still one, we
> could call the destroy noticification which would disable the
> disconnect. (handler sends disconnect notify when its object is
> going away rather than when it is going away.)
>
> Number 2 isn't good if we get a warnign that we are trying to
> disconnect a connection id which is already there.
> Number 3 may be workable since in order for this to occure the
> handler must be emitting and thus used its argument list. However,
> there is no way to know is code depends on the handler sending
> its destroy notification late.
The above fix, and the above workaround should both work fine.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]