Re: Gtk+ signal bug

[Owen Taylor <otaylor redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes:

> > [ The destroyed will probably go away in GTK+-1.4, but this
> >   should work fine for now ]
> 
> Will there be something with a similar effect?  We don't need gtk+
> to actually destroy the object, it is fine if it continues living.
> (If a gtk+ object continues living and appears to the gtk-- system
> later, we currently just consider it to be a new widget and create
> a fresh wrapper.) We simply want to have the item removed from its 
> container and break unnecessary dependencied because all C++ connections 
> are about to go south.
> 
> (Making destroy less fatal will help us a lot in that the gtk+
> object can't be destroyed with the proxy still alive would prevent
> gtk+ from making walking wounded.)

The idea is not to remove ::destroy, but to simply remove the 
destroyed state. The problem now is that most widgets don't
properly handle checking whether they are in a destroyed state,
so attempts to access a destroyed widget are completely 
unpredictable in their effect.

What gtk_widget_destroy() would essentially mean is "break all
references to other widgets". This typically would result in
finalization, but if a refcount was preserved, one could then go back
and reuse the widget in a different context.
 
> > (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.)
> 
> You are right that with managed objects, the explicit disconnect
> never happens.  The invarient is that if gtk+ doesn't clean up
> we will.  In managed objects, gtk+ sends notification to all
> of our signals so that surpress their disconnects.  Thus the
> only case this effects is the unmanaged ones.  Thus we never
> had any problems with destory.  The gtk+ object always goes
> before us and cleans up most of the stuff.
> 
> The unmanaged one is still pathological thought because if gtk+
> emits a signal and we are in the dtor, we have class methods being
> emitted on partially constructed objects.  There has really been
> no way around that problem other than trying to get
> our stuff cut off as soon as we can.  I guess I could try
> surpressing the clean up of the gtk+ resources, but the clean up
> was there for another reason.  It is necessary to clean up
> our signals which share the same execution path.  The explicit disconnects 
> to gtk+ are required also for the user requested disconnect.
> Thus even if it is unnecessary busy work we will still need to do it.

So, what you are saying is that connecting to ::destroy on an
unmanaged widget or doing anything in the default handler for destroy 
is just a poor idea, and to try to ameliorate the damage, you
disconnect all signals first before you call gtk_widget_destroy()?

Sounds reasonable, though there are certainly other ways to
get into trouble.  

(Me, I think that unmanaged widgets are just generally a poor idea;
and in fact, that allowing 'delete' at ALL is just inviting
'delete this' problems. But anyways...)

Regards,
                                        Owen