alternateSelectedControlTextColor
alternatingContentBackgroundColor
controlAccentColor
controlBackgroundColor
controlColor
controlTextColor
disabledControlTextColor
findHighlightColor
gridColor
headerTextColor
keyboardFocusIndicatorColor
labelColor
linkColor
placeholderTextColor
quaternaryLabelColor
secondaryLabelColor
selectedContentBackgroundColor
selectedControlColor
selectedControlTextColor
selectedMenuItemTextColor
selectedTextBackgroundColor
selectedTextColor
separatorColor
systemBlueColor
systemBrownColor
systemGrayColor
systemGreenColor
systemIndigoColor
systemOrangeColor
systemPinkColor
systemPurpleColor
systemRedColor
systemTealColor
systemYellowColor
tertiaryLabelColor
textBackgroundColor
textColor
underPageBackgroundColor
unemphasizedSelectedContentBackgroundColor
unemphasizedSelectedTextBackgroundColor
unemphasizedSelectedTextColor
windowBackgroundColor
windowFrameTextColor

NSColor is a nice (NeXT) API though, color calibration is important to some people. It supports CMYK (printing colors), ICC Color Profiles and all of that stuff most people don't care about.
Any way here's a list of names of all of these special colors in macOS 11 BigSur (the list probably hasn't changed much in newer macOS) dynamic 'System' color list:
[code]
alternateSelectedControlTextColor
alternatingContentBackgroundColor
controlAccentColor
controlBackgroundColor
controlColor
controlTextColor
disabledControlTextColor
findHighlightColor
gridColor
headerTextColor
keyboardFocusIndicatorColor
labelColor
linkColor
placeholderTextColor
quaternaryLabelColor
secondaryLabelColor
selectedContentBackgroundColor
selectedControlColor
selectedControlTextColor
selectedMenuItemTextColor
selectedTextBackgroundColor
selectedTextColor
separatorColor
systemBlueColor
systemBrownColor
systemGrayColor
systemGreenColor
systemIndigoColor
systemOrangeColor
systemPinkColor
systemPurpleColor
systemRedColor
systemTealColor
systemYellowColor
tertiaryLabelColor
textBackgroundColor
textColor
underPageBackgroundColor
unemphasizedSelectedContentBackgroundColor
unemphasizedSelectedTextBackgroundColor
unemphasizedSelectedTextColor
windowBackgroundColor
windowFrameTextColor
[/code]
You would only need to use these if you really care about matching custom drawn buttons and feilds (our 'classic' controls) to the macOS appearance and user color preferences. Apple doesn't provide a lot of user customizable color options anyway. I was only interested in matching the control highlights and focus border from the System preferences colors, as usual it turned out to be more than I'd bargained for!

I'm added these handlers to OXT AppleImagingLib. They can be used to get the other non-dynamic color lists that come with macOS as well (like the 'Web Safe Colors' list for example).

Apple really didn't make it easy to figure out! These special dynamic NSColor obj don't come with their current RGBA (Red,Blue,Green,Alpha) values available. You have to first create CoreGraphics (C based API) CGColorSpaceRef for 'Device RGB', then create an NSColorSpace obj and then init that with the RGB CGColorSpaceRef ref, then you can use that NSColorSpace obj to covert the dynamic NSColor obj to another new NSColor obj that has RGBA components, and then you can read the RGB values as floating point numbers, which we want 0-255 numbers so then we need to multiply each by 255... shwew!

In between fighting off the spambots, backing up and updating these forums, and trying to find/or compile the now-walled-off 'pre-built' binaries for compiling the macOS Engine and externals, I squeezed in a few minutes to talk to my unpaid intern (ChatGPT) about using ObjC to get the RGBA color values for these dynamic macOS System colors...
[attachment=0]NativeControlAccentColor.jpg[/attachment]
:D

defaults read -g AppleAccentColor

You can read the AppleAccentColor value from the shell by running
[code]defaults read -g AppleAccentColor[/code]

Introduced in Mohave, macOS 10.14+ with the following colors:
nil: blue
-1: graphite
0: red
1: orange
2: yellow
3: green
5: purple
6: pink
If the value is nil (default blue) you actually get an error that reads:
"The domain/default pair of (kCFPreferencesAnyApplication, AppleAccentColor) does not exist."

For macOS 11+:
nil: multicolor
-1: graphite
0: red
1: orange
2: yellow
3: green
4: blue
5: purple
6: pink
nil is now the default multicolor appearance, and blue has been moved to 4.

So if you're trying to make your app behave like a real (Apple Human Interface compliant) macOS app, like the IDE currently does NOT, then you need to get this value and make your app's hiliteColor match it. The problem still then is what are the component RGBA values of 'graphite' for example? To further complicate things, the colors are dynamic, so the RGBA values of 'purple' are going to be different depending on if macOS is in regular Dark or Light mode, or 'vibrant' dark/light. To get the actual [b][i]current[/i][/b] RGBA values of 'graphite', 'purple', etc. we need to query an NSColor object which means Extension Builder (probably AppleScript/ASObjC could do this trick too).

[quote=FourthWorld post_id=6285 time=1706988643 user_id=51]
[quote=OpenXTalkPaul post_id=6282 time=1706985173 user_id=50]
I'll try to sneak in some time later to get ChatGPT to write the binding strings for us.
[/quote]
Have you found a GPT provider whose training set is exclusively compromised of works where consent has been explicitly provided?

I have fun playing with GPT, but until the lawsuits get sorted out I don't ship anything with them.

https://www.reuters.com/legal/microsoft-openai-hit-with-new-lawsuit-by-authors-over-ai-training-2024-01-05/
[/quote]
I haven't been using ChatGPT all that much lately, I've mostly used it for tedious tasks like writing lots of Foreign Function Interface binding strings for me. Beyond first teaching it about the language(s) and correcting bad results to train it while using it (sometimes it will still throw in something way off like BASIC syntax), the results generally make me fairly certain that what it has 'trained' on was a lot of data pulled from GitHub, and in my particular use case, it's looking at [b] Extension Builder code THAT I WROTE[/b] which is probably the bulk of the LCB + FFI bindings source that's available on GitHub. The reason I know it must have looked at my code is because of certain things like the way its names variables or the handler names to bind to. I'm OK with that, my source is all already public license. Anyone else using it / training it to do xTalk stuff that is worried about their results being shared or put into another data set should probably read the terms and disclaimers before making an account and using it for that.

I will say the next decade is going to be very interesting technology wise. I'm sure there's many (more) lawsuits to come. I'm aware of adverts of AI companies claiming to be 'IP liability protected' or something like that, which seems like a bogus claim to me (unless they're accepting ALL legal responsibility, which I doubt).

[quote=OpenXTalkPaul post_id=6282 time=1706985173 user_id=50]
I'll try to sneak in some time later to get ChatGPT to write the binding strings for us.
[/quote]
Have you found a GPT provider whose training set is exclusively compromised of works where consent has been explicitly provided?

I have fun playing with GPT, but until the lawsuits get sorted out I don't ship anything with them.

https://www.reuters.com/legal/microsoft-openai-hit-with-new-lawsuit-by-authors-over-ai-training-2024-01-05/

To Emulate OS UI Kits or Not To Emulate OS UI Kits, that is the question, I'm pondering before the rest of my weekend gets busy...
I was trying to emulate the appearance of macOS Sonoma pup up menu using an Popup menu 'classic' control and changing its properties, which I had to do dynamically due to limitations with what can be done with that type of control. You can get close to the way a native popup menu looks but be not close enough IMO. A widget could be set up that could probably come much closer to matching native controls, FFI could be used to use an actual native popup but then you should still need to write code to do approximation appearance, like a visual proxy for the 'native' look and feel to draw while you're in Edit mode or looking at the stack on another platform for which that 'native' widget is not native.

One of the things about darkMode on macOS is that [b]system[/b] colors are dynamic. Why I mean is the highlight color you pick for accent Color in the system menu, lets say you pick a florecent purple in darkMode, when the mode is toggled back to lightMode and you look at that color in the system prefs panel, it's now going to be a dark purple instead of a florescent purple. This color change is done automatically to maintain readability on the reversed color scheme.

So how do we know what colors our apps should be using if they're custom rendering controls (which OXT does) for things like a button's foreColor, textColor, hilitecolors, focus or accent color, etc.? I'm not sure if there's another way to get that dynamic color information from the system, but there is definately a way to get it using Objective C:

https://developer.apple.com/documentation/appkit/nscolor/ui_element_colors?language=objc

I'll try to sneak in some time later to get ChatGPT to write the binding strings for us.