On Sun, 2002-11-10 at 16:28, Murray Cumming wrote: > gtk_container_destroy() destroys its child widgets, regardless of any > extra outstanding refs. Not everybody knows that. > > ** The problem: > But gtkmm likes to make this optional, because it fits better with C++. > We do this by overriding gtk_container_destroy(). But that's no good > when adding a gtkmm widget to a GTK+ container. For instance, when > gtk_scrolled_window_add_with_viewport() creates a non-gtkmm GtkViewport > and puts the gtkmm widget inside it. > http://bugzilla.gnome.org/show_bug.cgi?id=97729 > > ** A solution: > I'd like to give control back to the child widget, by changing > gtk_container_destroy() so that it checks some > "does_not_want_to_be_destroyed_by_container" qdata in the child widget > before calling gtk_object_destroy(). It wouldn't break API, and > shouldn't affect performance. Is this acceptable? > > Murray Cumming Hello, please forgive my ignorance, but cannot the Gtk::Object be simply marked as invalid when the corresponding GtkObject is destroyed? Or does the design[0] of Gtkmm assume that a Gtk::Object has allways an associated GtkObject? Thanks, Tassos [0] or philosophy, or architecture - you get the idea :-) -- Tassos Bassoukos UNIX does not prevent you from doing stupid things because that would also prevent you from doing clever things
Attachment:
signature.asc
Description: This is a digitally signed message part