Re: Allowing GTK+ child widgets to prevent their own destruction

[Owen Taylor <otaylor redhat com>]

murrayc t-online de (Murray Cumming) writes:

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

I don't like this idea ... it's unfortunate that gtkmm binds 
deleting a widget to the ::destroy signal, since that doesn't
correspond to how GTK+ actually works; but I don't think
the way to deal with this is to make the GTK+ model even
more complex.

Regards,
                                        Owen