GNOME Bugzilla – Bug 374420
symbolic colors not reset correctly
Last modified: 2006-12-11 09:16:12 UTC
There is a bug when changing the symbolic color xsetting. If a color was first defined, but then is removed, it's value does not change. Even if there is a default value set in the gtkrc. This can be easily reproduced: 1. Use a theme like the following: gtk-color-scheme="asdf: #ff0000" style "default" { bg[NORMAL] = @asdf } class "GtkWidget" style "default" 2. unset the gconf key (/desktop/gnome/interface/gtk_color_scheme) 3. start an application with the theme, the background is red 4. set the gconf key to "asdf: #00ff00", application correctly changes to green 5. set the gconf key to "" at this point, nothing changes, but as the value from the theme is not overriden anymore, the background should be red again.
I am currently adding support for colour schemes to gnome-theme-manager, so this is really important to get fixed before GNOME 2.16. Users need to be able to revert to the default colour scheme without having to restart every gtk+ application! (Confirming bug as I also experience the same problem)
This appears to be happening because the new value of the gconf key is merged into the existing color scheme rather than replacing it. If you have a two-entry gtkrc (yes, the newline after #ff0000 is essential): gtk-color-scheme="asdf: #ff0000 ghjk: #00ffff" style "default" { bg[NORMAL] = @asdf fg[NORMAL] = @ghjk } class "GtkWidget" style "default" and then you set only asdf: gconftool-2 --type=string --set /desktop/gnome/interface/gtk_color_scheme "asdf: #000000" then the foreground colour will remain cyan while the background goes black. Obviously merging in nothing changes nothing. Explaining Benjamin's results. Since this is appears to be by design and is public API changing it may be ill-advised. As an alternative, how about letting "None" be recognised as an instruction for "clear this gtk-color-scheme entry". This should get the desired effect (and allow even more fantastic tricks for the three people who really care). Demonstration patch to follow shortly.
Created attachment 76960 [details] [review] Parse "None" as an instruction to remove the color entry This is a rough-cut of the patch. It works well enough to be able to reset the color scheme with a command like: gconftool-2 --type=string --set /desktop/gnome/interface/gtk_color_scheme "asdf: None" There are complaints about the gtkrc being invalid afterwards though: it looks like removing random entries isn't appreciated. So the question is: would this be a suitable solution to this bug?
No, unfortunately that's not a suitable solution. If symbolic colours are removed from the gconf key, then their values should be reset to the values defined by the gtkrc. Symbolic colours should never be removed completely as this will mean gtk+ won't know what colours to use for the theme (as you found out).
I'm currently working on a patch to do what you ask. It should be completed tonight, but my broadband connection is currently acting like a meerkat on speed (I'm resorting to a modem for this) so no guaranteed when you'll see it.
A little problem: the gtkrc code stores its info in the same hash as gtk-color-scheme and relies on the fact that it merges entries rather than replacing them (that's how it merges multiple gtkrc files, e.g. the user's and the theme's). Fortunately the code does tag which source the setting came from so it is possible to change behaviour based on source. Currently I have code that sets the hash as desired but then induces the gtkrc code into an infinite loop... i.e. no patch tonight.
Created attachment 77049 [details] [review] Make changes to gtk-color-scheme from the Xsetting do an over-write rather than merge. Only a day late, here is the patch to make the gtk-color-scheme xsetting (and hence the gconf key) do an overwrite instead of a merge. It has some sub-optimal parts, as the comments note, but there is weirdness where the gtkrc code effectively resets the xsetting (to the same thing as before) and I don't feel confident about untangling that right now. Try it out.
That patch certainly produces the behaviour I was looking for.
Callum's patch looks approximately right. I think merging makes only sense for GTK_SETTINGS_SOURCE_RC_FILE (since you could conceivably combine several rc files which define different sets of symbolic colors). It is a bit unfortunate that we need to keep the 4 separate hash tables around, and then construct a merged one on top of that, but thats life.
2006-12-11 Matthias Clasen <mclasen@redhat.com> * gtksettings.c: Change the way in which color scheme information is merged to correctly handle vanishing colors. (#374420, Benjamin Berg, patch by Callum McKenzie) Also allow to separate entries in color schemes by ';' instead of newline.
Thanks Matthias. That other little change you added will be really nice too.