Re: Gtk+ signal bug

[Karl Nelson <kenelson ece ucdavis edu>]

> 
> How could you not manage to destroy?

Not entirely sure, but if someone derives from a very early object
in gtk-- (like widget) and then writes a lot, we don't get the 
destroy until the wrapper is a Gtk::Widget.  ( Until recently, I
wasn't bothering with the destroy until the Object stage, but
set_parent became a problem.)

>  
> [...]
> 
> > > (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?
> 
> Not really, though the particular way you do it:
> 
> (Something like:
> 
>  g_idle_add_full (gtk_main_level(), ...)
> 
> IIRC) could use some improvement. I actually can't fathom
> what this is supposed to do ... you should certainly offset
> that as
> 
>  G_PRIORITY_HIGH + gtk_main_level() 
>  G_PRIORITY_DEFAULT + gtk_main_level() 
> 
> or 
> 
>  G_PRIORITY_LOW + gtk_main_level() 
> 
> 
> or something. But even then, I'm  lost. The effect of this is
> that objects ->destroy()'ed in more deeply nested main loops get
> destroyed after objects ->destroy()'ed in less deeply nested main loops.

Waht I am trying to write (and feel free to correct my implementation) is
that I don't want to run this idle in a more deeply nested gtk_main(),
wait until you are back the main level where you were created. 
It is fine if the destroy is held beyond that point and we don't care 
about order.

I don't know if gtk+ can create the effect.  After fixing the 
bug in interactions with gtk+, delete this seems to be working correctly
as well, so I don't know if the queued destroy is necessary.
The queued destroy saved us most often just when things were going wrong in
deletion order.

--Karl