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 300780 - Can't change background color for GtkButtons under Windows
Can't change background color for GtkButtons under Windows
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.6.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
: 316322 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-04-15 18:14 UTC by Charles Kerr
Modified: 2009-11-03 17:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Charles Kerr 2005-04-15 18:14:46 UTC
Please describe the problem:
Wimp ignores a button's background style settings when it draws a button,
so gtk_widget_modify_bg() has no effect.

modules/engines/ms-windows/msw_style.c::draw_box() delegates button draws to
modules/engines/ms-windows/xp_theme.c::xp_theme_draw(), which style->dark_gc
for the drawing context that's passed to UxTheme.dll:DrawThemeBackground,
which does the real work.

Would using style->bg_gc in xp_theme_draw() be more correct?

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?
Yes

Other information:
Comment 1 Dominic Lachowicz 2006-03-10 16:22:29 UTC
*** Bug 316322 has been marked as a duplicate of this bug. ***
Comment 2 Charles Kerr 2007-01-23 17:03:29 UTC
IMO this could be closed as NOTABUG.

As per Jernej Simončič's comment in #316211:
  The same thing happens in native Windows applications, and not only
  that - try setting the colors yourself in the Advanced window of
  Display properties -> Apperance when XP themes are enabled.

And Dom Lachowicz's comment in the same ticket:
  We strive to behave like a native Windows app behaves, depending
  on whatever registry settings and themes are active, not how a
  Windows app might behave if you were running on Windows 2000.

If this is what happens to native apps under the Luna theme,
and gtk+ is trying to behave like a native app (which makes sense),
then the current state is the desired outcome.

(Or we could mark as `NOTGNOME' and re-file as a Luna theme bug
under Microsoft's bugzilla tracker ... oh, wait.)
Comment 3 Dominic Lachowicz 2007-01-23 17:11:01 UTC
Agreed. I think that this is the desired behavior, though I could very well be wrong. This is an existential question that the GTK+-on-MacOSX guys will soon face.

Is it better to 1) look and behave like a native app 2) look and behave as a GTK+ app 3) look and behave like some "hybrid" when an application developer has explicitly overridden a theme's settings.

I'd think that #3 is the desired behavior, but there's no way AFAIK to tell if an application developer has overriden a theme's settings. Pointers appreciated.
Comment 4 Bernhard Rumpler 2007-02-14 13:27:09 UTC
IMO settings done by a resource file should override the theme settings. Why else should it be possible, e.g., to set button colors in a resource file, if the theme overrides everything? The style priorities suggest this behaviour (rc has higher priority than theme).

We, e.g., have an application on windows that shall look like a windows applications, with some exceptions explicitly defined in the resource file.
Comment 5 Dominic Lachowicz 2007-02-14 13:39:32 UTC
The problem is that there is no way (in today's GTK+) to know if a user or developer has explicitly changed a theme's settings away from its defaults. There's now way to know what to override and when. This isn't so much of a problem when dealing with Win2k-style drawing (as we handle all of that internally), but becomes a huge issue when we delegate all of our drawing operations to Windows XP's "uxtheme" theming engine.
Comment 6 Tor Lillqvist 2009-11-03 17:06:19 UTC
As per comments 2 and 3, resolving as NOTABUG.