GNOME Bugzilla – Bug 765921
css colour lookup failure after gtk_style_context_save
Last modified: 2018-05-02 17:06:56 UTC
Created attachment 327190 [details] Test program With upcoming test program I get... welinder@lenovo ~/gtkwork/gtk+-3.20.3/tests $ make testcalendar && ../libtool --mode=execute ./testcalendar CC testcalendar.o testcalendar.c: In function ‘main’: testcalendar.c:61:16: warning: offset outside bounds of constant string [enabled by default] selector = next + 1; ^ CCLD testcalendar colour=rgb(255,0,0) colour=rgb(46,52,54) <--- Would you look at that! colour=rgb(255,0,0) (The warning is inside code copied from foreigndrawing.c; I think gcc is wrong here.) I don't see any reason why I should get a different colour just because the style context has been saved. This is with stock gtk+ 3.20.3 Bug 758442 seems related, but that is claimed to be fixed.
whats going on here is that gtk_style_context_save() creates a transient subnode of the current node. This sometimes has unexpected effects as you can see here. If you add a selector like "button.itembar * { color: blue; }" you will find that it matches inside the save/restore.
> ...creates a transient subnode... Isn't that an implementation detail that I shouldn't need to know about? And if I should know, it probably should be prominently spelled out as part of the documentation for gtk_style_context_save. It is currently described as a purely state saving method. Note, that this means that anyone following the advice on https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/ regarding get_color (i.e., use save+set_state+get_color+restore) will get the wrong colour.
Also, in my example, shouldn't the transient subnode inherit the colour setting of button.itembar?
-- 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/gtk/issues/621.