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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]