GNOME Bugzilla – Bug 109403
Some themes do not respect application .rc settings
Last modified: 2004-12-22 21:47:04 UTC
Offending thems- crux, Grand Canyon and Smokey blue. This problem occurs in Solaris Gnome2.2 build also.
Needs to be fixed in HEAD and gnome-2-2 branch
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Anyone got a fix for this? The time is running out for 2.2.x soon.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Checked this on a nightly Gnome2.4 build from 24th October 2003. This bug is still present. Blueprint theme is also affected. Offending themes: ----------------- BLUEPRINT Crux Grand Canyon Smokey Blue When using GOK (ignoring system theme preferences), changing to any one of the offending themes forced GOK's buttons to change.
Created attachment 24154 [details] [review] proposed patch
Attached is a patch that stops the theme change notification to be propagated in gok. So if the theme is changed while using gok. Gok won't be affected. Can I commit ?
It looks okay to me. Please add a gok Changelog entry and commit. thanks!
I've committed the patch. I've also added few lines to for the use of the default gtk engine. This way gok won't pick the desktop wide gtk theme.
I don't think this was the correct fix; GOK needs to respect the desktop themes like other applications! I am pretty sure this should be reverted. Erwann, I wish you had waited for me to have a chance to comment as well, since I was the source of the bug.
The desired behavior is for GOK to track system themes, but for pixmap themes not to ignore/override RC-file-based theme colors when applications read them in. Note that application-provided RC files are supposed to cascade from the system theme.
Erwann, perhaps you can shed some light on what is going wrong in the original bug report, i.e. why the pixmaps from pixmap themes are getting painted on the GOK buttons even though GOK is trying to use an application-installed .rc file. Perhaps we can modify GOK's rc file to suppress or replace the pixmaps, or perhaps something is inherently wrong with pixmap themes as far as application-installed RC files are concerned. I would not want GOK to use pixmaps in its RC file unless the cuyrent theme used pixmaps.
Before doing anything I'll need to know what is the bug definition exactly. As there are few contradicting statement in that bug report. Is it : - Some themes do not respect application .rc settings if it is, you need either to specify a custom theme engine in gok.rc file or use my patch. Otherwise the theme engine is inherited from the desktop preferences. or is it : - GOK needs to respect the desktop themes like other applications! in that case there is no bug as the custom resources are properly stored but not used by some themes (mainly themes using pixbuf) or is it : - why the pixmaps from pixmap themes are getting painted on the GOK buttons even though GOK is trying to use an application-installed .rc file it is because the user defined theme engine is used as there is no theme engine defined in the gok.rc file. Also note that there is no acceptable way of differenciating which theme is overwriting which gtk drawing primitive without modifying the gtk theming API which is something that should be avoided. Knowing that we cannot use user defined theme only conditionally (e.g. use the thinice theme but not Crux). Please give me a clear explaination of what the expected behavior is. Thanks, Erwann
OK - expected behavior is that pixmaps don't get painted on GOK buttons (i.e. GokButton class widgets). The fact that pixmap engines can and will ignore bg/fg etc style colors is IMO a basic flaw in the engine/GtkStyle system since it causes pixmap engines to behave very much differently from non-pixmap engines. I think there needs to be a way for an application style to explicitly override pixmaps _without_ specifying the engine; perhaps that it possible via use of engine-specific data in the gok.rc file, for instance providing gok-specific pixmaps to be used when pixmap engines are selected by the user, but I'm not sure how that would work in practice. Specifying an engine in gok.rc should _mostly_ solve the problem for GokButtons, but I did not have luck trying this so far (by specifying the following line in the 'style' blocks: engine "" {} (which is supposed to specify the 'default' engine) or engine "gtk-default" or "default" or even "thinice" which I know is a correct engine name. If you could provide a patch that specified the default gtk+ engine for the styles specified in gok.rc only (but _not_ for the whole application, i.e. not the Gok settings dialog, etc.) that would be helpful, since the rc file docs don't really give enough to go on here.
Erwann: I tried style "no_pixmaps" { engine "hcengine" {} } class "GokButton" style "no_pixmaps" which worked pretty well (perhaps not as well as using the themed engine with suppressed pixmaps, but that doesn't seem feasible). However, I was unable to determine what the 'default' engine name should be (it seems wrong to rely on the high-contrast engine for this when the default gtk+ engine is all that's needed).
Created attachment 24278 [details] [review] gok rc file modification
The patch attached makes the widgets that use the gok.rc style ignore the user set theme. This is cleaner and it is also a more find grained solution as only the widget using these style will be affected. (I've only added engine "" { } in each style). (Note that if you are using gok from HEAD you'll have to disable the call to gok_main_stop_theme_change_notify as I didn't remove the patch from cvs). Let me know if that it was you want.
Erwann: why wouldn't it be better to apply the patch I suggest in my comment, regarding class "GokButton" style "no_pixmaps" ?
Created attachment 24309 [details] [review] proposed patch 3
The difference between your approach and the one is the attached patch is that only the widgets using the styles defined in gok.rc are only using the default gtk engine. With your approach none of the GokButton widgets will ever use the user defined theme. So as you told me at the moment it is fine as the GokButton are only used in conjuction with gok.rc defined style but this could be restrictive if in the future you decide to use GokButton for another purpose. Anyway the 2 solutions are very similar, so pick the one you prefer and let me know which one to commit. (I've just attached a patch with your solution in it).
We want the user to allow users the option of have gok buttons obey the user defined theme. In fact there is such a setting in gok. Something like a "Use Desktop Theme Preferences" checkbox if I recall correctly.
Make that "We want to allow users..." (blush)
David: as long as erwann reverts his previous patch which provided gok_main_stop_theme_change_notify, his latest proposed patch should do what we want. That's because we only read gok.rc if the gconf key for "use gtk+ theme" is FALSE. Therefore we have two behaviors: (1) user chooses gtk+ theme for all GOK buttons, and gets theme-generated appearance (without GOK's color coding) (2) user opts _not_ to use gtk+ theme, in which case we read gok.rc which overrides the current theme engine when rendering GokButton objects, and applies appropriate gok color styles to GokButton objects. Erwann, I think your latest patch ('proposed patch 3') is fine, thanks for your help!
Understood. Sounds good. Thanks all.
I've removed my previous patch and integrated the rc based one.