In BigSur the “pressed” button of a toolbar automatically gets its label-color (“General” etc.) according to the selected accentedColor in the preferences.
Accordingly I create the icon using the same accentedColor, in my case “blue”:
var c as color = ColorGroup.NamedColor(“controlAccentColor”)
The problem is that switching to DarkMode, c remains “blue” while the label automatically switches to some greenish color.
In the Preferences of Xojo, the toolbar’s pressed button works OK: i.e. in DarkMode both the label and the picture change their color, from blue to greenish.
Is there something I’m missing?
NB. I know that docs and forum refer to this DarkMode issue. Hoping to get some light.
Thanks.
In the App’s event handlers, create an event called AppearanceChanged(). It is called whenever you change to dark or light mode. (This event can only be created on App, not windows or controls).
https://documentation.xojo.com/api/deprecated/application.html#application-appearancechanged
Set your colors in there, then refresh any windows or controls that have custom colors like your icon so they immediately switch over - otherwise they won’t change until the app comes to the front again.
Mark,
whatever I do (your suggestion, or putting the code in the paint event of a window or in a canvas) the accented color returned is the same in Light and Dark Mode.
I wonder how others do when dealing with systemIncons in Preferences Toolbar.
Thanks for answering.
Without seeing your code, it’s hard to tell why it’s not working.
I have something like this in my AppearanceChanged Event.
iconColor = If(Color.IsDarkMode, color_Dark, color_Light)
iconColor, color_Dark and color_Light are color properties.
It checks the mode, assigns the proper color to iconColor, and then calls methods to change the colors in applicable controls.
@Mark_Sweeney
Without seeing your code, it’s hard to tell why it’s not working.
Here is the code, the same as above:
var c as color = ColorGroup.NamedColor(“controlAccentColor”)
I expect that, in the debugger, you’ll see that c is the same both in Light and Dark Mode.
You may also test it in the paint event of a canvas:
var c as color = ColorGroup.NamedColor(“controlAccentColor”)
g.forecolor = c
g.fillrectangle 0,0,g.width,g.height
then switching from Light to Dark Mode or viceversa, the canvas keeps showing the same color.
I wonder if it’s a bug - I get the same color returned in light mode and dark mode.
I used the code below in the open event, and Appearance Changed. Started with dark mode, switched to light mode, and then back to dark mode. I got the same color each time - &h000A5FFE
Var c As Color
c = ColorGroup.NamedColor("controlAccentColor")
Var hexColor As String = c.ToString
MessageBox (hexColor)
NamedColor calls right into the macOS to get the color using the name you passed so it’s hard to think that it’s a bug (we use it in the IDE and don’t see this sort of issue).
If you continue to see an issue, please file a bug report with an example project (the one with a canvas will do) and a mocked up picture of what you are expecting with a screenshot of what’s actually happening so we can probably uickly get to the bottom of this.
@Greg_O_Lone
filed bug report
<https://xojo.com/issue/66357>
I’ll submit the example project when requested.
MacOS version 11.6
Xoio 2021r2.1
Could the issue be that my MBP is not M1?
Meanwhile, here is the workaround I’m using at present: commenting the IF part of it, switching to DM the color --on my MBP-- remains the same as in LightMode.
Sub Paint(g As Graphics, areas() As REALbasic.Rect) Handles Paint
var c as color = ColorGroup.NamedColor(“controlAccentColor”)
if IsDarkMode then
if c = &c0A5FFE00 then//blue
c = &c2BC8FF
elseif c = &c92379600 then //purple
c = &cFC7EFF
elseif c = &cF1318C00 then//pink
c = &cFC7DFF
elseif c = &cFB384500 then//red
c = &cFC869100
elseif c = &cF26C1600 then//orange
c = &cFED740
elseif c = &cFDBB0900 then//yellow
c = &cFFFF24
elseif c = &c52B03600 then//green
c = &c9EF775
else//graphite
c = &c0A5FFE00//revert to blue
end if
end if
g.ForeColor = c
g.FillRect 0,0,g.width,g.Height
End Sub
The accent color doesn’t change when you switch to Dark Mode. You can see that in the screenshot below:
The button has the blue - correct - accent color. Your code makes some arbitrary color.
@Beatrix_Willius
Yes, I use the arbitrary color as a workaround because the canvas, on my MBP, does not show the right System accentedColor after switching to DM. That is, the canvas color is the same in LM and DM.
Unless what I expect is my misunderstanding (it would not be the first time…).
The first two screenshots show the same (System) blue both in LM and DM.
The third one shows the workaround color, more or less as it shows in Mail, Safari etc.
Look at my screenshot. There is NO DIFFERENCE for the accent color in Light and Dark Mode.
Yes, I looked at it.
So, since I see that you get the right DM color and I guess you tested it on an ARM machine, I guess that the issue is related to Intel machines.
If that were the case, I would wrap wrap the workaround into
#if TargetARM
#endif
Here are 2 screenshots of what I see in Mail - Preferences (Safari etc.). The first one in LM, the second one in DM.
They are different. Yet on my machine, when coding for canvas or toolbar, they are the same, unless I use the hardcoded values.
Change your ToolbarButton.buttonStyle to toggleButton and use toolbarButton.pressed to get the system to draw the correct color for you.
The togglebutton name “General” is correctly refreshed by the system without any code of mine: screenshot 1 shows the button NOT pressed, while the other 3 screenshots show the button pressed. So, the label “General” gets its proper color according to the button state.
The icon is a systemIcon, and its color should be correctly set by
var c as color = ColorGroup.NamedColor(“controlAccentColor”)
and you can see that in DM mode (screenshot 3) the color remains the same as in screenshot 2. Even the debugger shows the same color 0A5FFE00 both in LM and DM.
That’s why at present I make use of the hardcoded code, in order to get the correct color (4th screenshot). “Correct”, in the sense that it looks as in Mail/Safari Preferences.
Same issue with canvas.
I’m pretty sure that the issue is related to my MBP which is an Intel machine.
Before we get too far here, let’s dispel some issues mentioned above:
On macOS,
- The built-in named colors do change between light and dark mode. Yes, all of them.
- By default, Unsaturated UI colors (black, white and grays) usually flip between being light and dark whereas saturated colors (red, yellow, etc) usually only change subtly between light and dark)
- The colors you get back from the named colors can change based on what’s underneath them, including whatever your desktop picture is, so screenshots and pixel color samples are useless between machines or even different parts of your screen. For testing, I suggest using a black desktop background and make sure there are no app windows behind your app.
- Colors can be affected by the user’s Accessibility settings for visual impairments. If you try turning on High Contrast, you’ll see what I mean.
- As Sam mentioned, the type of control can also change which colors you get.
Oh and
6. Colors are also affected by the Color Space applied to your monitor and your app.
No screenshots or pictures used.
Done. Issue persists.
Accessibility settings are the default ones.
My two type of control are Canvas and Toolbar buttons. But at present I’d restrict myself to Canvas.
If you refer to System Preferences > Display, it is “Built-in Retina Display” with Resolution set to “Default for display”; and Color: Color LDC. Nothing else.
If only I could test an ARM machine! Or if it were possible for you to test the Canvas on an Intel MBP…
Thanks.
Open “App Wrapper” and select “Preferences” from the App Wrapper menu.
Do the toolbar icons work as you expect them to do so?
I forgot, if you have the Ohanaware App Kit, there’s source code there on how to create a toolbar that matches Apple’s “Preferences” style.
