Named colors

[filipnavara]

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.

[aaronfranke]

Related discussion, which may make this issue obsolete: https://github.com/dotnet/runtime/issues/32418

[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).

[charlesroddie]

Understood. I see several problems:

1. Unless this is specced out to guarantee a clear separation of the types, there is a strong risk that it will be done in some terrible complex interconnected way. Especially because the name of this repo now has "Maui" in it and Maui is what was Xamarin and Xamarin would definitely do it that way.
2. To justify putting this in the repo, all targets would need to support names (which I believe they don't) and not only that but the same names.
3. How could you write a test for consistent rendering across platforms if some settings (e.g. dark mode) could cause platforms to render things differently at different times?

[filipnavara]

Unless this is specced out to guarantee a clear separation of the types, there is a strong risk that it will be done in some terrible complex interconnected way.

I intentionally omitted the API shape because of this. Thanks for raising it as a concern which I agree is a valid one.

To justify putting this in the repo, all targets would need to support names (which I believe they don't) and not only that but the same names.

I don't think that is necessarily a requirement but most, if not all, of the targets have the concept. I checked it exists on macOS, iOS, Android and to some extent on Windows.

For me it's important that there is a way to express it at all even if at some point there is a platform specific way to create the named color. To put this into context. Suppose I care only about iOS and Android and I maintain my own color catalogue (ie. some XML/Plist that is embedded in the app and maps my own names to colors). Then I want to be able to use these colors for a custom drawn control in Maui but with late binding of the actual values at the graphics layer (since the OS usually knows the system settings and can choose some variation of the color catalogue). I could think of many other use cases where it's just matter of being able to pass an existing named color through some layer implemented through Microsoft.Maui.Graphics.

Actually unifying the names may be difficult or even impossible (even though the system color set has huge overlap between different OSes). I consider acquiring the system colors by name a separate issue from being able to pass them through the layer.

How could you write a test for consistent rendering across platforms if some settings (e.g. dark mode) could cause platforms to render things differently at different times?

I think the question comes from the assumption that I would use Maui.Graphics along with the custom controls to get consistent rendering across platforms. While that may be one of the reasons why the library exists it's certainly not the only use case. I want to share code across platforms for things like rendering avatar icons with borders (simplest example I could think of) but set the border to the color of native borders of the platform.

While in many cases I could get by with early conversation to RGB(A) color type it requires me to watch for color scheme changes. It's forcing me to replicate what the OS already provides. It doesn't account for different color spaces (eg. the OS may use different colors for monitor with wider gamut). It also isn't future proof if Apple or Google decides to introduce some semi-dark mode, high contrast mode or anything similar (much like they did with the dark mode in the past years).