Lazarus Colors in Cocoa ... slightly off?

[Hansaplast]

I'm trying to use the correct matching color for items I'm drawing on a form (onDraw events) or controls that displaying on a form (eg. matching the background color of TEdit with the color of TForm - don't ask me why 😉).
However it seems that the Lazarus standard colors (clBackground, clWindow, clForm, etc) are slightly off when comparing them with the colors used by the Form and standard controls.


Is this something that still needs fine tuning in Cocoa?
Or am I just not quite understanding how I can use these standard colors?


As an alternative I tried grabbing a pixel color from canvas, so I could use that instead, but that always returns black on Cocoa it seems (again: maybe I misunderstand how to use Canvas.Pixels[]).


To illustrate the color issue, I did create a little app to display the colors.
As you can see not even the Form background color can be found in the standard colors.
Seems the natively drawn controls (? not sure if I got that right) have a slight more reddish hue to them than the cold standard colors. I did play with all kinds of color settings (screen color profile, night shift, warm/cold colors, different monitors, etc) to make sure that isn't the problem.


Any help or work around is appreciated.

[Hansaplast]

Totally forgot to post what versions I'm running:


Happens on macOS Sonoma 14.5 on both Intel and Apple Silicon. Have noticed this before though on Ventura and different Lazarus versions. Compiler directive "-WM11.0" set (seemingly temporary needed to make dark mode "work").


Current screenshot from:
Lazarus 3.99 (rev main_3_99-2110-g560115beea) FPC 3.3.1 aarch64-darwin-cocoa

[paweld]

Each component has its own default color, and by drawing on another component its actual color clDefault may be different from the form color.
You didn't provide the code so it's hard to comment - if you can, try the code from the attachment and let me know if it shows the correct colors.

[Hansaplast]

Hi Paweid!
Thank you for chiming in - it is much appreciated.


Your project example illustrates the effect.
The background color of the Form is more grey/blueish than the titlebar of your project.


At designtime they are almost the same color.
The form.color uses clDefault, a color I cannot match with any of the standard colors.


At runtime it seems to switch to the color clForm (or something like that), which could make sense, but is not the same color. (see screenshot)


Easiest way to reproduce with code; Start a new fresh application, just a plain form, without any modifications, you'll see exact the same effect: The color in design mode is being different than in runtime mode.


See second screenshot, which is a combination of 3 screenshots, since inactive windows will have a slightly darker color under macOS which I wanted to avoid.


From left to right in the second screenshot:


I created a blank form in XCode. I'll just call that "the correct colors" for a Form under macOS.


The second window in the screenshot shows the Lazarus TForm at designtime (I disabled the grid), which seems to use a color that seems about correct when comparing them with the XCode form.


The third one however, is that same Lazarus form at runtime, showing a more grey-ish.


So for some reason, at runtime the default (clDefault) color of the form is changed and seems to be "off".


Note: the warmer color that we see during design time, matches the color that I see with other macOS applications as well. Not sure why it would change at runtime.


This is just one example.
When assigning the color "clForm" for example to the TForm.color and a TEdit.color, then they both look the same kind of "dirty" greyish - unlike what one would see in XCode. However still slightly off (maybe this is what you meant).


Now I could use a dropper to pick that specific color at runtime, and hardcode it. But my fear would be that this color could be different again in the future with different OS versions for example. So I'd rather pick a color the right way (if there is any).
Initial though was using the standard colors, under the assumption those would be consistently be matching the system colors.


The alternative would be grabbing a pixel from the form (self.canvas.pixels[]), but under Cocoa this always returns the color black.


In the end I'm looking for a proper way to determine the Form color (or other controls), and just ran into this issue which may be a bug?


Note: when looking at some of my Cocoa applications that have been compiled a while ago, then this issue does not arise and the forms are the proper warmer color. So this change in color must have snuck in the code somewhere in the past year or so (just guessing).

[paweld]

Now I understand what you have a problem with, but unfortunately I can't do anything more because I don't have macOS.

[Hansaplast]

No worries - thank you for trying to help though 😊
(apologies if I didn't explain it better in the first post)

[Hansaplast]

For those running into this issue ...
Short answer: For the time being, there is no simple fix.

In more detail:
While talking to Rich, concerning a bug report about clMenuHighlight being the wrong color, I noticed that the color of the wallpaper has an influence on the standard colors as presented by Cocoa, which seems reason for these discrepancies.



AFAIK, LCL relies on static colors, where as modern macOS versions seem to have dynamic colors based on transparency, vibrance, effects etc.
I recall having seen something like this with Windows 10/11 when I was tinkering with Dark Mode, but I could be wrong.

Oddly enough the "effect", as described in my original post, is reversed when working in Xcode (grey at design time, adapted to the wallpaper at runtime).
I lack the knowledge to see what the (significant) implications for Lazarus may be.


Attached: screenshots from XCode, left = runtime, right = design time. One screenshot with wallpaper that is mostly orange, and one with most blue.