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 492721 - color schemes not robust against upgrades
color schemes not robust against upgrades
Status: RESOLVED INCOMPLETE
Product: gtk-engines
Classification: Deprecated
Component: clearlooks
2.12.x
Other Linux
: Normal major
: ---
Assigned To: gtk-engines maintainers
gtk-engines maintainers
Depends on:
Blocks:
 
 
Reported: 2007-11-02 15:02 UTC by Josselin Mouette
Modified: 2007-11-02 18:31 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Josselin Mouette 2007-11-02 15:02:17 UTC
Release 2.12 introduced two new components of the color scheme in Clearlooks: tooltip_bg_color and tooltip_fg_color.

However, if the user had customized his theme with a previous version, these two colors won't appear in his "gtk_color_scheme" (whether it is brought by .gtkrc-2.0 or by gnome-settings-daemon), because this variable is overriden as a whole.

So, there must be something like a default_color_scheme that specifies the default colors in the theme that can't be overriden by the user. Or alternatively, the colors could be all defined in separate variables. All in all, I fear this mandates some changes in GTK+ because I haven't found a way to do it properly.

See for example http://bugs.debian.org/444001 for the resulting behavior with a theme customised using gnome 2.18 and running gnome 2.20.
Comment 1 Benjamin Berg 2007-11-02 15:12:51 UTC
There should not be any problems. GTK+ merges the color scheme from the different sources (gtkrc, xsetting, application setting). That means that as long the themes gtkrc defines the colors in the "gtk-color-scheme" everything should work fine.
So the variable is _not_ overriden as a whole. The only way I can think of this happening right now is that if the theme does not specify default values for all colors it needs in the gtkrc.
Comment 2 Josselin Mouette 2007-11-02 15:50:05 UTC
Hmmm indeed, my initial analysis was wrong, as missing colors in the GConf settings propagated by g-s-d don't trigger any problem.

Do you know what could have caused the issue the user noticed then? I don't see anything relevant in the g-s-d or gtk+ changelogs. It's too bad he hasn't kept the GConf settings that triggered the issue.
Comment 3 Benjamin Berg 2007-11-02 16:37:12 UTC
I think that the only thing that can cause this issue is if the theme is broken and does not define default values for all the colors it needs. However I don't remember having an issue like that in any release of gtk-engines. (There was a type once, but that did not affect the validity of the theme, just the appearance  dialog. And it was fixed in 2.12.0.)
Comment 4 Josselin Mouette 2007-11-02 16:44:07 UTC
AFAICT this happened with a stock 2.12.0 that was freshly upgraded.

Anyway, this is the only report I have received, so I guess the only thing left is to close it due to lack of information.
Comment 5 Benjamin Berg 2007-11-02 18:31:06 UTC
Yup, closing as incomplete. If anyone is able to reproduce this problem, please reopen.