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

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

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

[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

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