Default System Colors

[Kevin Koltzau]

On Friday 19 November 2004 06:17 pm, William Poetra Yoga H wrote:
> OK, so I think windows/nonclient.c doesn't need to be changed, we just have to
> load a theme somewhere at wineserver startup.

This is an area that is somewhat in the air currently. There are 2 methods I am
toying with to theme standard window components.

1) Modify all wine widget code to support drawing with themes, in which case nonclient.c
would need to be updated.
2) Subclass all controls to do theme drawing when uxtheme.dll is loaded. This would
require very few changes, if any, to drawing code in wine, but would be harder to implement
and may duplicate a large amount of drawing code.

Windows uses a combination of those two methods, with the addition of a system
service to coordinate and cache data, unfortunately this may not be an option as it
would probably involve integrating theming into the wineserver which I doubt
Alexandre would approve of.

> But why is GetSysColor() better? If an application can change the system
> colors, then the GetSysColor() function's return value may be inconsistent
> (with the current theme color) which is not good. And how do we know that an
> application has changed the colors? So in this case I think it's better to call
> GetThemeSysColor() in windows/* code, right?

GetSysColor is better for the very reason that applications can change the
system colors. For example, under XP the user can override the colors of a
theme in the display properties.
When SetSysColors is called, it broadcasts a WM_SYSCOLORCHANGE
message to notify colors have changed.