GNOME Bugzilla – Bug 591085
GtkBuilder object ID bounded to GtkWidget "name" property
Last modified: 2010-02-18 07:05:09 UTC
Please describe the problem: Widgets' property "name" is being set from the object's ID during widget creation by GtkBuilder. Steps to reproduce: 1. Create GtkBuilder file defining some widget with id set to "myUniqueID" and the property "name" set to "myWidgetName". 2. Build the widget from the file with GtkBuilder. 3. Observe the "name" property value. Actual results: The property "name" is set to "myUniqueID". Expected results: The property "name" is set to "myWidgetName". Does this happen every time? Yes. Other information: According to documentation the widgets' "name" property should be used to "apply a style to widgets with a particular name in the gtkrc file". It implies that the name does not have to be unique. As it is now, the property in fact is bounded to GtkBuilder's unique object ID at the widget creation time with GtkBuilder. This defeats the original documented purpose of the widgets' "name" property. At the least if the "name" property is explicitly defined in the interface file, its value should be respected. As a workaround for custom widgets you can implement your own GtkBuildableIface set_name and get_name functions. (I think they should have been properly called set_id and get_id to prevent any confusion, but what's done is done - they're part of the API).
I'm running into the same problem. GtkBuilder breaks my theming by overwriting widget names. As a quick hack, I modified GTK+ to use an object data "gtk-builder-name" in the default gtk_buildable_set/get_name, and it seems to work, with correct theming.
Maemo bug as a consequence of this: https://bugs.maemo.org/show_bug.cgi?id=4718
Glade Bug 591076 is also related to this.
Created attachment 145623 [details] [review] Set the widget name if not set, other use object data
From discussing this with Tristan, conditionally setting the widget name seems to be a compatible approach. Of course this still needs testing to see if it works.
I remember a discussion on irc from the time before gtkbuilder was integrated, and already then the point was bought up that using the widget's *name* for the bulidable's *ID* is a really bad idea. They have completely different semantics and mixing them like that is calling for trouble. I'm all for fixing that by storing the builder ID separately. I would even go so far to unconditionally store the ID elsewhere because the application is free to set the widget's name at any point, and should not destroy the builder ID by doing so.
(In reply to comment #6) > I would even go so far to unconditionally store the ID elsewhere > because the application is free to set the widget's name at any > point, and should not destroy the builder ID by doing so. I'm with Mitch here.
(In reply to comment #6) > I would even go so far to unconditionally store the ID elsewhere > because the application is free to set the widget's name at any > point, and should not destroy the builder ID by doing so. Yes, storing the ID elsewhere would also fix the Maemo bug Claudio was referring to in comment 2. Especially when the widget name is used for themeing, and the ID from GtkBuilder is needed to identify the correct object one is looking for. +1 from me for this solution.
Mitch, what exactly do you mean storing it elsewhere ? FWIW, totally agree that we just should not set the widget name based on the builder id at all, can we just stop doing that (and leave the id be the id and leave the name be the name ?) ?
By elsewhere i mean using g_object_set_data() as in the attached patch, just unconditionally (no matter if the widget's name is set or not).
Comment on attachment 145623 [details] [review] Set the widget name if not set, other use object data This patch should use set/get_qdata(), and it should do that unconditionally.
Created attachment 148604 [details] [review] Always use object data
Comment on attachment 148604 [details] [review] Always use object data Looks good to me.
Created attachment 148740 [details] [review] Always use object data, copy and update docs When I was about to commit, I noticed two things: we probably should copy the name, since we can't rely on the string being static, and I forgot to update the documentation earlier. It should say that object data is used, not the widget name. The updated patch does both.
The patch looks good, but should still use set_qdata()/get_qdata() to avoid the string -> quark conversion all the time.
Created attachment 148835 [details] [review] Use a quark to store the name
That looks perfect now.
Pushed to master.
This will cause at least a little bit confusing to pygtk programs which expects widget.get_name() to return the theme/buildable name. They would have to use gtk.Widget.get_name(widget) and gtk.Buildable(widget).get_name() to be sure that the right name is actually fetched, now when they are diverged. Over and out.
For what I want, such pyGTK+ programs have been obviously wrong and just worked coincidentally. Same for applications in any language making such assumptions.
(In reply to comment #19) > This will cause at least a little bit confusing to pygtk programs which expects > widget.get_name() to return the theme/buildable name. They would have to use > gtk.Widget.get_name(widget) and gtk.Buildable(widget).get_name() to be sure > that the right name is actually fetched, now when they are diverged. Fwiw, invoking unbound methods with an object instance is indeed ugly... a better approach would be an API addition like get_buildable_name() that calls into the right method, just like the panel applet bindings do for the set_flags() method. See e.g. http://mail.gnome.org/archives/gnome-devel-list/2009-December/msg00002.html and http://mail.gnome.org/archives/gnome-devel-list/2010-January/msg00001.html
*** Bug 607221 has been marked as a duplicate of this bug. ***
GtkUIManager also use gtk_widget_set_name, is this a bug too?