I agree this would be useful, especially for custom drawing and controls that need to sit naturally beside the built-in desktop controls.
My current thinking is that these should not be fixed Colour constants, because they are theme-dependent and can change with light/dark mode or accent changes. I’m leaning towards a separate desktop API, something like:
SystemColours.WindowBackground
SystemColours.ControlBackground
SystemColours.LabelText
SystemColours.FocusRing
SystemColours.SelectionBackground
SystemColours.SelectionText
SystemColours.Accent
The open question is what these should represent:
- Native operating system colours, as far as each platform exposes them.
- The actual Avalonia theme colours that Objo desktop apps are using.
I’m inclined toward option 2 because it would make custom drawing match Objo’s controls more reliably, and it should behave more consistently across macOS, Windows, and Linux. Native colours sound attractive, but the mappings are uneven across platforms and may not always match what the Avalonia controls are actually rendering.
I’d be interested in what others expect here: should SystemColours mean “the platform’s native colour values” or “the colours used by the current Objo/Avalonia desktop theme”?