After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764622 - Gtk.Widget.set_name not setting the "name" property, get_name not returning it
Gtk.Widget.set_name not setting the "name" property, get_name not returning it
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Bindings: GTK+ GStreamer WebKitGTK+
0.32.x
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-05 02:59 UTC by Michael Gratton
Modified: 2018-05-22 15:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Gratton 2016-04-05 02:59:18 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
Comment 1 Luca Bruno 2016-04-07 18:38:10 UTC
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.
Comment 2 Michael Gratton 2016-04-07 23:47:40 UTC
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. :)
Comment 3 GNOME Infrastructure Team 2018-05-22 15:33:42 UTC
-- 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.