GNOME Bugzilla – Bug 518002
Custom Container example prints warnings on terminal
Last modified: 2009-07-10 10:23:19 UTC
Mailing list thread: http://mail.gnome.org/archives/gtkmm-list/2008-February/msg00083.html "I've executed the custom container example of the Gtkmm Book. When I closed the applications the following warnings were displayed: (lt-example:24330): Gtk-WARNING **: GtkContainerClass::remove not implemented for `gtkmm__GtkContainer' (lt-example:24330): Gtk-WARNING **: GtkContainerClass::remove not implemented for `gtkmm__GtkContainer' This happens with Gtkmm version 2.12.4."
I've looked into this a little bit and it looks like in the function Container_Class::remove_callback_normal(), it fails the following check: if(obj && obj->is_derived_()) which means that the on_remove() virtual function doesn't get called but instead the base class->remove() function gets called. I don't know enough about how the is_derived_ function works to know why this happens.
Fixed. This warning was only shown when we really didn't want to do anything, so it was harmless: 2008-03-08 Murray Cumming <murrayc@murrayc.com> * gtk/src/container.ccg: remove_callback(): When just calling the C callback, because the C++ object has already been destroyed, don't even call the C callback if the GType is exactly GtkContainer. This avoids a useless warning from GTK+ about an unimplemented remove() default signal handler. This happens when deriving from Gtk::Container - remove() really is implemented - it's just that we don't call our own implementation when that would be impossible. Bug #518002 (Jonathon Jongsma).
Fixed the fix. :-) commit 4474ebb25f0309bb88e890b118db78beed5261d5 Author: Daniel Elstner <danielk@openismus.com> Date: Wed Jul 8 21:43:40 2009 +0200 Correct base type check in Container_Class::remove_callback() * gtk/src/container.ccg (Gtk::Container_Class::remove_callback): In order to test for the abstract GtkContainer parent class, actually compare against the parent type instead of making invalid assumptions about the derived type. By means of the alternative Glib::ObjectBase constructor, it is possible to create a custom GObject type different from the standard one. Pushed to master. Anywhere else it should go?
yeah, the original fix was applied to gtkmm-2-12, so I manually applied it to -14, -16, and master. So I guess you need to apply your fix to -14 and -16 as well (but only if we plan on making new releases of them I suppose)
We never know what we plan, so please someone commit any 2.12 fix to anything newer than 2.12 too.
Oh, now that I think about it, daniel's fix should probably to be applied to the original fix in 2-12 as well.