GNOME Bugzilla – Bug 764622
Gtk.Widget.set_name not setting the "name" property, get_name not returning it
Last modified: 2018-05-22 15:33:42 UTC
Calling Gtk.Widget.set_name() in Vala does correctly set the widget's "name" property, and calling Gtk.Widget.get_name() does not return it. For example, running the following: > Gtk.Label = new Gtk.Label("test"); > test_label1.set_name("test_label"); > stdout.printf("test_label1 name: %s\n", test_label1.get_name()); > > Gtk.Label test_label2 = new Gtk.Label("test"); > test_label2.set_property("name", "test_label"); > stdout.printf("test_label2 name: %s\n", test_label2.get_name()); Will print: > test_label1 name: test_label > test_label2 name: (null) There's some weird interaction with Gtk.Buildable.{set_name,get_name} going on - in the above example test_label1 will have it set and test_label2 will not. So the Gtk.Buildable calls are taking priority somehow? Explicitly casting the label to a Gtk.Widget before calling set_name() does not seem to help. This is pretty annoying when using CSS styling because it means you need to use GObject.set_property("name", ...) to set the CSS id of the widget, instead of Gtk.Widget.set_name() as one would expect to work, per the docs. GTK+ 3.20.2 Vala 0.32.0
Yes, set_name() is from Buildable. We have two ways I think to fix this: 1. Add `new set_name()` and `new get_name()` to Widget. Then if you have a widget, those will be called. If you want to call the Buildable ones, you have to cast to Buildable. This will be a very subtle change that will break much existing code. 2. Add `set_widget_name()` and `get_widget_name`. This is preferable to avoid breaking existing code.
I wonder how many people need to call Buildable.{get_name_,set_name}(), since as far as I can tell could only be used/useful if you are generating or introspecting a widget tree for XML serialisation. Hence if you did take option (1) it might not actually break anything. The only uses of it in the wild I could find were: http://stackoverflow.com/questions/23722112/cant-set-css-to-specified-widget-in-gtk, which the adivce in the end was "yeah it doesn't work just set a class on the style context instead" and https://code.launchpad.net/~elementary-pantheon/wingpanel/new-wingpanel/+merge/85254, where it is commented out and a again a class was used instead. Further, since all the docs state use Widget.set_name to do CSS blah blah that's what people are going to try just calling that, find it not work as expected, then use a workaround, as above. No one wil discover (2), so it's not even worth do. So I'd argue that (1) is minor break and is petty easily justifiable. :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/535.