Re: Gtk+ signal bug

[Karl Nelson <kenelson ece ucdavis edu>]

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

Okay, that sounds good.  We are using destory for exactly that 
function.  (and just dealing with side effects). 

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

Yes, that is about it.  I can't remove destroy entirely because 
people often wish to connect a "when this window closes destroy
the application."  My current solution is to have every dtor in
the system call destroy first thing.  This causes it to work
like gtk+ did the destroy.   However, for testing I have to check
that even if we don't manage to destroy at that time, that
if we get down the the object level we don't let any connections
live.

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

Always, but then any system allows one to shoot oneself in the
foot.  The point here is just to make it happen infrequently.

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

Very true.  Unfortunately, you really can't prevent unmanaged
objects and still be working with C++.   My perfered solution
to "delete this;" is "manage(this)->destroy();".  In other words,
surender the object and then tell it to destroy.  For managed
objects destroy is queue til the idle.  Is there a better 
way to queue such commands?

--Karl