GNOME Bugzilla – Bug 709049
gtk_widget_destroy() on a GtkHeaderBar tries to gtk_container_remove() if from its GtkWindow
Last modified: 2013-10-06 03:23:40 UTC
gtk_window_set_titlebar() calls gtk_widget_set_parent() on the titlbar widget. But, of course, it's not the Window's (GtkBin's) child. This seems to be the first widget in GTK+ that can't have gtk_container_remove(gtk_widget_get_parent(widget), widget); called without a warning. This is something that gtkmm has expected for many years. We can hopefully add an extra check to avoid the warning, but it seems a bit odd.
It is not the bin child - it is an internal child, more or less. Admittedly, we muddy the waters a bit by letting you provide your own widget for it. But I don't think it is too unexpected that you can't remove it with gtk_container_remove if you can't add it with gtk_container_add.
Created attachment 256165 [details] test_headerbar.c
Yes, sorry, of course there are lots of internal widgets, and we shouldn't expect to be able to remove them. But this widget is "added' by gtk_window_set_titlebar(). It's not unreasonable to think of that as a widget-adding function such as gtk_box_pack(). However, I've since figured out that it isn't gtkmm at all that's trying to remove this widget. It's GTK+ trying to remove it when the GtkHeaderBar is gtk_widget_destroy()ed, which is somthing that gtkmm calls. This test_headerbar.c test shows that, when you click on the button. I guess that this should not cause a warning.
Created attachment 256166 [details] test_headerbar.c
Created attachment 256405 [details] [review] patch: GtkWindow: Override gtk_container_remove () Proposed patch.