[Bug 42204] Inconsistent usage of control colors results in "broken" 3D effect of control borders

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Jan 14 06:34:57 CST 2017


https://bugs.winehq.org/show_bug.cgi?id=42204

--- Comment #7 from Rimas Kudelis <rq at 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)
> > 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.


More information about the wine-bugs mailing list