Color is missing Default and Accent

[mattleibow]

These two "colors" were nice to have so that there was a way to tell the renderers that either the default platform color or the platform accent color should be used.

Using this dummy color allows the actual to be determined at runtime on a particular OS. This is also good at hiding a concept from shared code that cannot be pre-determined. For example accent colors could change between OS and user prefs.

Having a real color would require some events to be raised and then when setting colors they will need to be requested by the user or somehow tracked.

Switching to a class (#56) or using nullable, does sort of help with this, but also moves the issue. Assuming "null color" means "default color", we still have to resolve "accent color". But now we also need to determine what is a "no color" vs "default color"

These is some discussion in the Discord on this: https://discord.com/channels/732297728826277939/732297916680765551/830071063555080254

No color is null, transparent has an alpha of 0, default color and accent color are handled by the UI layer. They way I approach it in my apps is that default and accent color are provided by a style manager within my UI toolkit.

There is also a separate style manager/watcher/theme handling needed. Not sure what is best at this point:

1. Magic colors that are resolved at the handler levels.
2. Colors retrieved/events and explicitly set.

The Xamarin.Forms Color had a special enum field to flag a color as a default color or as a RGB/HSL color. WinForms has a state field. And this is also used by WPF in a weird way with a struct with sub-color structs... Not sure if this is the right way, but it is a way.

This can be a thing (not sure it is a good thing, but still a thing):

class/struct Color {
    ColorType _type;
    double/float _red, _green, _blue, _alpha;
}

enum ColorType {
    Default, 
    Accent,
    RGB,
    HSL,
}

Relates to parent issue: #58

[charlesroddie]

Duplicate of #48

[hartez]

To answer Jon's question from the parent issue - in Forms, Color.Default really just means "let the native platform decide". So the color should be whatever it would be absent any cross-platform code, taking into account any native themes. And if the native theme changes, the color should change accordingly. This includes things like "light/dark" theme changes or system accent colors changing.

(There are certainly some bugs in Forms's implementations of this, but that's the general idea.)

So it's really just a way for the cross-platform code to say "from a cross-platform perspective, we don't care what color this thing is". The same thing could probably be done by simply making the cross-platform colors nullable (either via Color being a class, or by using Color?).

Accent should be stored elsewhere, probably on some sort of per-platform bag of settings. Color was always the wrong place for it in Forms (as evidenced by the [EditorBrowsable(EditorBrowsableState.Never)] attribute that was put there to "hide" it from external use). The current design is awkward and doesn't leave any room for expansion to more platform colors.

Yes, it will technically be a breaking change to remove it. It will also be correct.

[Redth]

No change planned.