GNOME Bugzilla – Bug 765982
Changed behaviour of gtk_style_context_get_color
Last modified: 2018-05-02 17:07:09 UTC
Gtk+ 3.20 changed behaviour of gtk_style_context_get_color. It used to be correct to have a state argument different from the state of the context; now those have to be the same. This is unreasonable. I am sure there are good, internal reasons why the states must match, but gtk+ has all the pieces needed for hiding the change. It makes much more sense to have the work-around in one spot in Gtk+ than having the work-around in 100 places in 100 applications. The pain is 10000 times bigger in the latter case. The recommended work-around is save_state set_state (state) get_color restore_state although as pointed out in bug 765921, that doesn't actually work. Alternatively one can use old = get_state if (old != state) set_state (state) get_color if (old != state) set_state (old) I think this work-around should be added to gtk_style_context_get_color or further downstream. That will allow existing code -- including binaries -- to keep working. It will also work with already-changed code.
(In reply to Morten Welinder from comment #0) > Gtk+ 3.20 changed behaviour of gtk_style_context_get_color. It used to be > correct to have a state argument different from the state of the context; > now those have to be the same. Do we document anywhere that they *must* be? The GtkStyleContext doc only says: > Note that passing a state other than the current state of context is not > recommended unless the style context has been saved with gtk_style_context_save(). Which is really too vague: Why is it not recommended? It should explain why users might find themselves wanting to use that and why it may not work as they intuitively expect.
-- 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/622.