GNOME Bugzilla – Bug 743516
Split GtkBuilder's get_type_from_name() vfunc into two
Last modified: 2015-02-01 16:16:35 UTC
GtkBuilder's virtual function get_type_from_name() is used (via calls to gtk_builder_get_type_from_name()) for two different purposes: 1. GtkBuilder calls it to find out what kind of object to create. 2. GtkListStore and GtkTreeStore call it to find out what kind of objects are required in a GtkTreeViewColumn. This is probably no problem in applications that use gtk+ directly, but it is a problem in gtkmm, the C++ binding of gtk+. A C++ application uses class Gtk::Builder, with GType name gtkmm__GtkBuilder, derived from GtkBuilder. gtkmm__GtkBuilder overrides get_type_from_name(). When the override is called with a type name, let's say "xyz", it returns the GType of "gtkmm__xyz" if such a type has been registered, else it calls get_type_from_name() in GtkBuilder. This is good when get_type_from_name() shall tell what kind of object to create. We want GtkBuilder to build objects of gtkmm's derived types when possible. This is bad when get_type_from_name() shall tell what kind of object is required in a GtkTreeViewColumn. We want GtkListStore and GtkTreeStore to accept both xyz and gtkmm__xyz. They would, if they were told that the column shall contain xyz objects. A gtkmm__xyz is an xyz. The problem is described in gtkmm bug 742637. A solution would be to make a new get_type_from_name() that GtkListStore and GtkTreeStore can call. In gtk+ the new function will be identical to the existing one, but a language binding can override it differently. Does this seem too ridiculous and unnecessary? I understand that it's unnecessary in gtk+, but it would help in gtkmm. If we do add a new get_type_from_name(), shall it belong to GtkBuilder? To the GtkTreeModel interface? To GtkListStore and GtkTreeStore? If it shall belong to GtkBuilder, what shall the new vfunc be called? I can write a patch, but first I want to know in which class the new vfunc shall be added.
not sure I follow - list store and tree store only call the builder function in their buildable implementation, so they should always operate with the builder subclass that you supplied when you called one of the builder load functions. I don't see how the rules for type name resolution should be different in different parts of a ui file. Either you want to accept gtkmm types or you don't...
Let me guess, in gtkmm, you specify a type such as: FooBar And your builder implementation automatically looks for a wrapper type: gtkmm__FooBar Is that correct ? I don't think the proposed fix will solve the issue, if the above is the case, one might conceive of a derived GtkTreeStore or GtkListStore which accepts the gtkmm wrapper types, and overrides the buildable implementation to get at them, and then get's screwed by a double standard in GtkBuilder. Rather, you should be addressing gtkmm wrapped types with a different type name in the builder file, and have the GtkBuildable->get_type_from_name() chain up to the parent implementation when your 'gtkmm__' prefix is not found on the type. I may be wrong but I think this is how python deals with this.
I think this should be resolved on the gtkmm side, since it introduces this wrapper type business.