After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 98413 - Allow gtkmm to prevent child destruction
Allow gtkmm to prevent child destruction
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Widget: Other
2.1.x
Other Linux
: Normal enhancement
: future
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 97729
 
 
Reported: 2002-11-13 18:09 UTC by Murray Cumming
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
gtk_prevent_child_destruction.patch (2.75 KB, patch)
2002-11-13 18:11 UTC, Murray Cumming
none Details | Review

Description Murray Cumming 2002-11-13 18:09:17 UTC
Already posted to gtk-devel, without a reply:

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.

I have created a GTK+ HEAD patch for this. If it is accepted then I'd like
to apply it to 2.0.x too.
Comment 1 Murray Cumming 2002-11-13 18:11:56 UTC
Created attachment 12285 [details] [review]
gtk_prevent_child_destruction.patch
Comment 2 Owen Taylor 2002-11-13 20:02:41 UTC
Leaving the bug open to track that there is an issue for gtkmm,
though I don't think it is possible to handle in the GTK+ level;
making how destruction works in GTK+ even more complex is
very unnatractive.

Making an API addition like this in a stable branch like
2.0.x course something that we try really really hard to
do.

(It's still new API even if you avoid adding a symbol for it,
it just makes it ugly API...)

Comment 3 Murray Cumming 2002-11-15 18:43:51 UTC
We believe that we fixed this by overriding the dispose vfunc instead.