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

[murrayc t-online de (Murray Cumming)]

On Wed, 2002-11-13 at 20:56, Owen Taylor wrote:
> 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; 

I think that's a different issue. Apart from these unusual cases it
works well for us. People aren't crying out for the ability to have
access to widgets in unusable states.

> but I don't think
> the way to deal with this is to make the GTK+ model even
> more complex.

Well I didn't think you'd like it because it's a hack. But we don't seem
to have any alternative and it's not likely to be used by anything else
and doesn't affect anything but gtkmm. We're kind of screwed without it.

-- 
Murray Cumming
murray usa net
www.murrayc.com