Hi everyone
Is there a way to get the real colors used everywhere when using darkmode on Macos and on Windows ?
Like the window background color, the listbox background color, the background editfield color… ALL colors and background colors used everywhere ?
Are there constants other than the few contains in the color class ?
For MacOS you can get the colors from this list: UI Element Colors | Apple Developer Documentation
Use like this:
//Get the ColorGroup with a named color
Dim cg As new ColorGroup("windowBackgroundColor")
//Set that color to a rectangle's fillcolor
Rectangle1.FillColor = cg
3 Likes
If you want something a bit easier to use for Desktop, GraffitiColors has tons of color related functionality, including system-specific color functions that are named for the values they return. For cross-platform development, you can do something like:
g.DrawingColor = GraffitiColors.SystemAware.WindowBackground
Or if you’re focusing or refining a specific target, say macOS:
g.DrawingColor = GraffitiColors.MacOS.BackgroundWindow
These functions will return the color value returned by the system for the current theme, and the demo shows all colors available to the current system as well as what SystemAware functions return.
2 Likes
In fact, as Xojo is a cross platform tool, I’ll like to see Xojo constants for each color, non depending of an OS.
A “Window Background color constant” should be used in the same way on macos, Windows, ios or android…
There are some colors defined this way in the built-in Color module, such as DarkBevelColor, FrameColor, TextColor, but they’re woefully lacking. You can also use ColorGroups and select the Named tab. I’m really not sure how well that works cross-platform, however.
I would suggest that, if you want the built-in functionality expanded, you open an issue.
I think that should be:
Dim cg As new ColorGroup.NamedColor("windowBackgroundColor")
Sorry I meant,
Dim cg As new ColorGroup = ColorGroup.NamedColor("windowBackgroundColor")
But, I see there is a constructor that compress it into one. So you are correct. Apologies.
Drop the “New”
The shared method ColorGroup.NamedColor returns a color. Not a color group.
Meaning it will return the color for the current mode: light or dark.
1 Like
So it would seem, which is very odd in its self.
Well the good news is that it’ll be correct regardless of whether the app is in light or dark mode, so you could just use that in code where you need it.
ColorGroup has an Operator_Convert on it which returns a Color as well, but the NamedColor shared method was meant to avoid the extra method call, which can add up if you use a lot of custom color in your app.
Be warned, I have found a situation where colorGroup.namedColor will return the wrong color.
Makes testing UI elements in Xojo that much harder than other tools.
I recently highlighted what Xojo needs to do in order to correctly handle dynamic colors, but this requires some serious engineering effort that I honestly doubt they’re interested.
In the mean time, the most reliable method is to rasterize the color at draw time, you can probably find a bunch of API 1.0 solutions for doing this.
You know, I’ve seen you post this a few times recently about things that you think Xojo should be doing differently. It would be really helpful if you would also post a link to the “recently highlighted” items so everyone could weigh in.
It would also be helpful to know what that is instead of just posting it and walking away.
Just so everyone knows, the only time that Apple guarantees that the dynamic colors will be correct is within a paint event… even if the AppearanceChanged even has just fired.
If you’re going to cache colors, you should use the AppearanceChanged event as an indicator to clear the cache, but then only pull colors and store them in the cache in paint events.
g.forecolor = colorgroup.namedColor( "labelColor" )
Returned the light themed color even when in dark mode. i.e. A dark text color, instead of the light grey it should have been.
Resorting to using declares works as expected.
Which illustrates that Xojo is not handling Apple’s dynamic colors correctly.
Another example is using a declares to set text colors of a label, or the background in the Open event of a control works, with no need to update the colors when the Theme changes.
With pure Xojo you need to do this manually and as Xojo doesn’t expose the appearanceChanged events of NSViews, you must do it all from the appearanceChanged event of the App class. Even then, rasterizing the color can be wrong.
These are all things that wouldn’t be a problem if Xojo had someone dedicated to working on the Mac platform and the intention of keeping their framework up to date.
This is not a dig against you @Greg_O, It’s an illustration that Xojo’s priorities have hurt its capabilities, and made things that should be simple, more difficult than needed. But I can say that until I’m blue in the face and it won’t change a thing.
Edit: Here’s another post where I point out the complications of trying to build native Mac apps with Xojo’s framework, and have had to resort to declares.
On macOS this is no longer a solid color and trying to draw it will give you results that are inconsistent with native macOS applications.
Instead you need to use a NSVisualEffectView with the windowBackground material, which requires either a declare library or plugin as Xojo have not implemented this control, despite it being present for almost 10 years.
Hopefully Xojo can tell you which system color that they’re using or what the current constants are if they’re not using system colors.
textBackgroundColor or alternatingContentBackgroundColors[0]
However both of these colors will give you mismatching values, they need to be set as the background of a NSBox to get the actual color. Again Declares or a plugin library will help you here.
Check out Aqua Swatch to see the system colors as they should be, different materials, system fonts, icons etc… Aqua Swatch on the Mac App Store
Well you’re right. Xojo would have to completely overhaul how they do color, and personally I don’t see that being a priority.
If you notice though… the colors that are used by the macOS UI controls do change automatically by default. We had to do a lot of magic to make that possible with the system the way it was without breaking the other platforms and still work properly on older versions of macOS. Had Windows and Linux gotten their acts together at the same time, it would have been easier, but to have to adapt to three different systems at different times was just miserable.
2 Likes