[Bug 42204] New: Inconsistent usage of control colors results in "broken" 3D effect of control borders
https://bugs.winehq.org/show_bug.cgi?id=42204 Bug ID: 42204 Summary: Inconsistent usage of control colors results in "broken" 3D effect of control borders Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: rq(a)akl.lt Distribution: --- Created attachment 56838 --> https://bugs.winehq.org/attachment.cgi?id=56838 Wine color theme used in the screenshots I have configured my copy of wine to use colors as similar as possible to my dark GTK theme (which is basically Adwaita Dark). I was hoping to achieve modestly 3D-ish look, so I configured colors appropriately using buttons as reference. I'm attaching my theme as a registry file. However, I noticed a few inconsistencies in how Wine uses these colors when drawing borders. Particularly: 1. the bottom and right borders of sunk-in elements such as combo boxes, text fields, checkbox fields, radio buttons, notepad text editor widget, various lists (such as file and folder listing in File/Open dialog), slider bars and probably others have their two colors mixed up. 2. top and left borders of some embossed elements, most notably, the scrollbar buttons and thumbs, and drop-down list buttons have their two colors mixed up. 3. top and left borders of Window drop-down menus have their two colors mixed up. 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). 5. I'm not sure if named widget groups such as ones in winecfg tabs are supposed to look embossed or not, but they certainly do not. I'll be attaching a few screen shots shortly, depicting status quo on the left and desired looks on the right. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42204 --- Comment #1 from Bruno Jesus <00cpxxx(a)gmail.com> --- An screenshot would be useful pointing the problems. Are you testing on wine 2.0-rc5? Or something close to that? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42204 --- Comment #2 from Rimas Kudelis <rq(a)akl.lt> --- Created attachment 56839 --> https://bugs.winehq.org/attachment.cgi?id=56839 Screen shot & desired look mockup -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42204 --- Comment #3 from Rimas Kudelis <rq(a)akl.lt> --- (In reply to Bruno Jesus from comment #1)
An screenshot would be useful pointing the problems. Are you testing on wine 2.0-rc5? Or something close to that?
No, but I tested with 1.6.2 and 1.9.6 and haven't noticed any difference among them. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42204 --- Comment #4 from Nikolay Sivov <bunglehead(a)gmail.com> --- Hi, Rimas.
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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42204 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #5 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- With the default color theme, I don't see any of the reported issues. 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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42204 --- Comment #6 from Nikolay Sivov <bunglehead(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #5)
With the default color theme, I don't see any of the reported issues.
That's not surprising.
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.
It's would be useful to have a screenshot from Windows vs Wine with distinct colors so any difference is apparent. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42204 --- Comment #7 from Rimas Kudelis <rq(a)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.
https://bugs.winehq.org/show_bug.cgi?id=42204 --- Comment #8 from Rimas Kudelis <rq(a)akl.lt> --- On the other hand, SDHL (the first approach for sunken elements) has the advantage of keeping the order or neighbouring colours intact, which might be important for pseudo-3D look like one I tried to achieve with my theme. -- 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.
participants (1)
-
wine-bugs＠winehq.org