GNOME Bugzilla – Bug 372642
on_*() methods are not called for wrapped objects
Last modified: 2006-11-24 21:34:34 UTC
Please see the attached test program. It displays a window with an entry and a combo box entry. Both have signal handlers connected to `changed' signal and are supposed to print a message from on_changed() method. However, it seems that on_changed() for the combo box entry is never called. (I can't check if this is still true with the newest Gtkmm. If it is not, just close the bug.)
Created attachment 76228 [details] testcase program
It works for me. I guess you have built glibmm and gtkmm yourself, and you are using the configure options to disable API.
Mmm, I haven't quite specified how it _should_ work. Does it print two different lines in the terminal after a change to any of the two (different) entries? Now that I think of it, it probably cannot work with current GTK+ architecture at all. Entry in the combo box is created using gtk_entry_new() by C-level code and so it cannot know about C++ methods, right? Please see bug/wish #373110. Gtkmm is preinstalled Debian Sarge one, not customly compiled. It is old (2.4.10), though.
When typing one character into the enty: entry changed entry changed (signal) When typing one character into the comoboxentry: combo box entry changed (signal) You call to "Glib::wrap_register (gtk_entry_get_type (), &Entry::wrap_new);" is also completely useless. I don't know what that's meant to achieve. Are you really expecting GtkComboBox to magically instantiate an instance of your C++ class? Or have I misunderstood? Please reopen if you still think this is a bug.
You may be surprised, but it will just crash without "useless" call. And the C++ class is "magically" created: each constructor is called once, one from "new Entry()" line, another one when wrapping GTK+ entry from "combo_box_entry.get_entry ()". It is a bug, but more a bug of GTK+ than a bug of gtkmm. Therefore I won't reopen it. GTK+ calls gtk_entry_new(), which creates entry of GTK+ C class. It doesn't know about what gtkmm or my program wraps on top of that and therefore on_changed() method is not called. So: object of appropriate C++ class _is_ created, exactly because of "useless" wrapping. However, it is not really attached to C object, because that one is created by gtk_entry_new() which knows nothing about inheritance. I suggested you to look at bug #373110, but apparently you didn't.
Sorry you did.
> You may be surprised, but it will just crash without "useless" call Ah, I didn't see that you were registering your own wrap_new() rather than re-registering the existing wrap_new(), and depending on that somehow. This is a massive hack that has never been intended to be supported. You shouldn't be messing about with these internals of gtkmm or GTK+. But that's a discussion for your bug #373110, I think.
Then inheritance of gtkmm classes is yet more restricted in usage. Granted, you can inherit widgets and instantiate your own using constructors, but if registering wrappers is not supported, it cannot be used for GTK+-created widgets at all... Why restrict users of the library? Do you expect this machinery to change or is there another good reason?
I'm happy for people to register new C++ wrapper classes for new GObjects types, though I'd prefer them to just let gmmproc take care of doing that. I think it's obviously a hack to change an existing registration, so that methods start returning YourEntry instead of Entry. I'm tempted to prevent re-registration. It should be quite obvious that this is not really public API.
It is quite obvious that this is listed in the docs. At least in 2.4.10. You may of course forbid things for no good reasons, just because you think it is right. This will cost me reimplementation of already implemented things. I don't see why you have problems with overriding wrappers. Of course, it is properly valid to require that the overriding object is inherited from gtkmm objects --- it is assumed by gtkmm anyway. It is an unstated assumption now it changes nothing to require it somehow by compiler check. But I don't see how adding additional restrictions will improve things.