GNOME Bugzilla – Bug 438652
GTK+ menu colors wrong on XP in 8-bit mode
Last modified: 2016-06-08 04:07:15 UTC
Please describe the problem: When using 8-bit color on Windows XP, GTK+ displays application menus incorrectly. Menu text is shown using a white foreground. This is impossible to read if your menus have a white background. I noticed this under GTK+ 2.10.10, and verified that it still happens under 2.10.12. Steps to reproduce: 1. Configure a Windows XP machine to use 8-bit color. (I'm using RDP) 2. Run a GTK+ application, e.g. gtk-demo.exe or Wireshark. Actual results: Menu text is displayed with a white foreground. Expected results: Menus should be readable. Does this happen every time? Yes. Other information:
Created attachment 88225 [details] gtk-demo.exe application menu under 8-bit color on XP
Created attachment 88227 [details] gtk-demo.exe application about box under 8-bit color on XP
Created attachment 88228 [details] Wireshark menu under 8-bit color on XP
Created attachment 88229 [details] Wireshark build info under 8-bit color on XP
Just to clarify - white text is used for other widgets as well (such as trees, lists, and buttons).
I am tempted to remove all the ugly explicit (and apparently broken) support for 8-bit (palettized) mode for GTK+ 2.12, and just pretend it is true colour mode and let Windows handle it the best it can...
(In reply to comment #6) > I am tempted to remove all the ugly explicit (and apparently broken) support > for 8-bit (palettized) mode for GTK+ 2.12, and just pretend it is true colour > mode and let Windows handle it the best it can... > Go for it, Tor.
Hmm, unfortunately removing all code for pseudo-color support from gdk/win32 (thus pretending it is 24-bit true color, and letting Windows handle the actual mapping to palettes and stuff) still results in gtk-demo looking quite unusable over a 256-color RDP connection... Need to do more thorough debugging.
Is there any way we (the Wireshark community) can help move this forward? Running Wireshark on an 8-bit display under Windows is a fairly common use case. As a result, we've offered an optional GTK1 build in releases up to and including 1.0. We're in the process of removing GTK1 support in the main (post-1.0) trunk, but this means that some users may be left in the cold if at some point we stop supporting 1.0 _and_ this bug hasn't been fixed.
Created attachment 108925 [details] [review] Suggested patch When I now try again and just drop all the GDK_VISUAL_PSEUDO_COLOR, DIRECT_COLOR and STATIC_COLOR code and related palette manipulation code from gdk/win32, *and* use cairo 1.5.20 (a snapshot of the soon coming cairo 1.6), GTK+ works relatively nicely in 256-color mode. So, as soon as cairo 1.6 is released, I am going to commit this patch to GTK+. You who build GTK+ for Win32 yourself, please try the patch.
BTW, it would probably be a good idea if the ms-windows theme engined disabled itself when on non-truecolor display modes.
(In reply to comment #11) > BTW, it would probably be a good idea if the ms-windows theme engined disabled > itself when on non-truecolor display modes. > Why? How bad does it look (versus a native Win32 app)? And how do you tell if you're on a non-truecolor display? I think that we can do this in msw_theme_main.c - if we're not on a truecolor display, return g_object_new(GTK_TYPE_RC_STYLE). That should use the default theme.
> How bad does it look (versus a native Win32 app)? I haven't now tried on a "real" 256-color mode display, but only by setting "Run in 256 colors" on the Compatibility tab of the Properties of gtk-demo, and (a copy of) notepad.exe. At least this way the scrollbar in gtk-demo when using the ms-windows theme looks worse than that in notepad. I don't know how well the "Run in 256 colors" setting corresponds to real 256-color mode.
> how do you tell if you're on a non-truecolor display? Check gdkvisual-win32.c: const gint rastercaps = GetDeviceCaps (_gdk_display_hdc, RASTERCAPS); const int numcolors = GetDeviceCaps (_gdk_display_hdc, NUMCOLORS); gint bitspixel = GetDeviceCaps (_gdk_display_hdc, BITSPIXEL); etc.
Hmm. Actually now when I check with trunk, 256-colour mode does not look so bad after all. Menus certainly seem to look OK. I probably won't commit the patch after all...
Created attachment 111429 [details] [review] Slightly updated patch
I mean, if somebody actually uses 256-colour mode, dropping the code for it will definitely mean for instance the colour selector will look like crap. Not to mention apps that display photos, like GIMP. With the existing palettized mode support code they actually look not that bad. That is with trunk and cairo 1.6.4.
Is there a workaround for this bug?
(In reply to comment #18) > Is there a workaround for this bug? In our software package (Wireshark), we still offer a GTK+ 1.2 version that works in 256-color mode.