https://bugs.winehq.org/show_bug.cgi?id=42204
--- Comment #7 from Rimas Kudelis rq@akl.lt --- Created attachment 56846 --> https://bugs.winehq.org/attachment.cgi?id=56846 Windows 10 screenshot with the inconsistencies in non-styled app zoomed in
(In reply to Nikolay Sivov from comment #4)
- Menu bar color is not used for menu bar. Instead, menu background color is
used (which I suppose is meant for drop-down menu backgrounds).
To use menu bar color for menu bar you need to switch to flat menus, see msdn docs regarding SPI_SETFLATMENU parameter.
Does it _have_ to be that way in Wine as well? Are there any drawbacks to always using the flat menu?
(In reply to Nikolay Sivov from comment #6)
It's would be useful to have a screenshot from Windows vs Wine with distinct colors so any difference is apparent.
I can confirm that Windows has same issues as well. Attaching a screenshot. But I wonder – does it _have_ to be that way in Wine as well? Here's why I think it shouldn't.
Windows has been getting rid quite effectively of this "classic" look for quite some time now. "Visual styles", which mostly ignore these colour settings, have been around since Windows XP, and most applications are using them by now, only some really old ones aren't. In Windows 10, I can't even find a way to change these colours without applying a theme (changing them directly through the registry has no immediate effect), and even then, I suspect that only a minority of applications (the ones that don't have "Visual styles" enabled) will care about them.
On top of that, Microsoft sometimes tends to hold on to little issues like these in the name of predictability, existing documentation and whatnot. Especially when it concerns non-default functionality.
In fact, even with Windows 10 it's quite difficult to come up with a pleasantly looking dark theme due to the numerous assumptions that are built into applications and themes. The best I could come up with requires using Aero Light style, and still gives me useless crappy looking borders here and there.
On the other hand, for Wine this classic look is still the default and perhaps the only one that works well enough, and while it seems to interpret these colours the same way Windows does, if that Windows interpretation were to be deemed broken or inconsistent, I think Wine could and should improve it. And I do think it is somewhat inconsistent, because it makes it difficult to achieve 3D effect, or even a flat effect with thin (1 pixel) borders around elements.
(In reply to Olivier F. R. Dierick from comment #5)
It could help if you replace one color at a time with "255,0,255" in the registry to point out the names of the problematic colors.
The colors I think are problematic are the following: - Controls Highlight - Controls Light - Controls Shadow - Controls Dark Shadow
The way I would expect them to be used is rather simple. For any raised 3D element, its borders should be coloured somewhat like this:
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHD HLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLSD HL SD HL Controls Background / Controls Text SD = HLSD (top/left → bottom/right) HL SD HSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSD DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
and for any lowered (sunken) 3D element, they should probably be coloured like this:
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSL SDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDHL SD HL SD Controls Background / Controls Text HL = SDHL (top/left → bottom/right) SD HL SHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHL LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
or like this:
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDH DSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSLH DS LH DS Controls Background / Controls Text LH = DSLH (top/left → bottom/right) DS LH DLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
Proper flat look with 1-pixel borders could be achieved either way, but the second approach for sunken elements (DSLH) has an additional benefit that each colour ends up being used exclusively just for external or just for internal borders, which means that if the user would decide to hide one of these borders by using "Controls Background" colour for it, ALL elements would either keep their size (if internal border is hidden), or would consistently appear 2px smaller (if external border is hidden). With SDHL, either just raised, or just sunken elements would appear smaller, but not both.