secondaryLabelColor) and safely roundtrip them through wxColour.Īttached is an illustration of the wrong background as compared to Finder. I think we need to support NSColor natively, not only to be able to preserve exact system colors, but to allow user code to use system colors unsupported by wx (e.g. My motivating reason for looking deeper into this is that the titlebar and toolbar are subtly wrong in wx apps - they have a wrong shade of dark grey and I think this is related to not using NSColor natively. I did some digging and its due to using the HIThemeBrushCreateCGColor call to query a couple of specific colors. The text label colors seem correct, but the flat areas and control background remain the light gray. I am attaching a testing background wallpaper as used in the first article it's very helpful for better seeing the effects in play. I was testing our apps with Mohave and in 'Dark Mode', wxWidgets apps do NOT display properly at all. ![]() These articles are very useful regarding this: You can see this in wxListBox if you move it around in dark mode, the background color subtly changes to reflect the background wallpaper behind it (this is not sidebar-like translucency, but a solid, adapted color). It's not just being different for dark and light modes, but the system colors can change appearance subtly based on view material/appearance, of which there's many more now, and even depending on window position on screen. NSColor really is much more dynamic/magic now. ![]() What about storing both RGB values and NSColor, then? ![]() OK, I understand but this way we still would have - at every usage outside draw - set NSAppearance.current to the effectiveAppearance, otherwise the CGColorRef would not be correct
0 Comments
Leave a Reply. |