Re: Gtk+ signal bug

[Owen Taylor <otaylor redhat com>]

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

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

How could you not manage to destroy?
 
[...]

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


Regards,
                                        Owen