Named colors

Some of the wrapped graphics APIs have concept of named colors (eg. NSColor on macOS). These could be system colors (eg. window background, border color) or custom catalog colors. Converting them to the internal Color type however loses their lazy resolution to actual RGB value (eg. the named color can have different color based on system wide dark mode / light mode). Is there any plan to expose this functionality? Even System.Drawing had it in some limited form.

[charlesroddie]

Even System.Drawing had it in some limited form.

This is a huge wart in System.Drawing.Color that needs correction. Adding something like names to the Color type causes ineffiency and complex interdependencies.

Maui (not Maui.Graphics) could have functions like getBorderColor:unit -> Color etc. or even tryGetColorFromOSNamedColor(name:string):Color?. That would allow users to get these colors without adding complexity to the Color type.

[filipnavara]

@charlesroddie I think there’s quite a distinction between color manipulation type and abstract color description type. System.Drawing.Color tried to do both at the same time and lacked a bit on both. I didn’t ask for specific API shape or even having one type for both.

Just like R,G,B is only describing a color when interpreted in a specific color space (eg. sRGB, Adobe RGB), named colors are also meaningful only within their respective color space (eg. dark theme, light theme).

This library specifically states the goal of abstraction over native graphics libraries for drawing. CoreGraphics has concept of named colors (extensible), Windows has concept of named colors (albeit limited).