The easy choice would be to use System.Drawing.Color
It converts from integers like 0xFFFF00
It converts from RGB strings like "255, 255, 0"
It converts from color names like "Yellow" or "Red"
However, it requires a reference to System.Drawing assembly, and it doesn't support xTerm's 256 color indexes (it would turn "220" into a shade of blue 0x0000dc)
A Better Way?
Since we're going to output escape sequences at the end of the day, there's no reason not to consider a custom Color class with byte R, G, B values and a ToString(bool Background) implementation that outputs escape sequences ...
It could remove the dependency on System.Drawing, and could still support all of the above conversions, and depending on the implementation, it could make calling some APIs easier.
It could handle "DarkYellow" (which isn't a named color in System.Drawing), and create more separation between "Green" and "DarkGreen" than System.Drawing.Color does, or even handle the 16 ConsoleColor names specially, resulting in the ConsoleColor ANSI sequence (which allows theming the core 16 colors, instead of using the pre-defined RGB values that System.Drawing.Color would give you)
Considerations
I don't consider supporting xTerm's colors a priority because our primary platform is Windows 10 which has full 16bit color. Older terminals that don't handle 16bit color should be fixed. However, for the sake of our xTerm and tmux using friends, I would like to support a preference variable like:
In this situation, we should be able to down-sample from 16bit colors to the nearest xTerm 256 or ConsoleColor Color.
In fact, even when in FullColor mode, when outputting escape sequences, we will want to still support the standard ^e[0;30;44m style combinations for the console colors, so that it's possible to use our module and still get "themed" color outputs as configured in the console preferences. (see the xColors module).
The easy choice would be to use
System.Drawing.Color0xFFFF00However, it requires a reference to System.Drawing assembly, and it doesn't support xTerm's 256 color indexes (it would turn "220" into a shade of blue
0x0000dc)A Better Way?
Since we're going to output escape sequences at the end of the day, there's no reason not to consider a custom Color class with byte
R,G,Bvalues and aToString(bool Background)implementation that outputs escape sequences ...It could remove the dependency on System.Drawing, and could still support all of the above conversions, and depending on the implementation, it could make calling some APIs easier.
It could handle "DarkYellow" (which isn't a named color in System.Drawing), and create more separation between "Green" and "DarkGreen" than
System.Drawing.Colordoes, or even handle the 16 ConsoleColor names specially, resulting in the ConsoleColor ANSI sequence (which allows theming the core 16 colors, instead of using the pre-defined RGB values that System.Drawing.Color would give you)Considerations
I don't consider supporting xTerm's colors a priority because our primary platform is Windows 10 which has full 16bit color. Older terminals that don't handle 16bit color should be fixed. However, for the sake of our xTerm and tmux using friends, I would like to support a preference variable like:
In this situation, we should be able to down-sample from 16bit colors to the nearest xTerm 256 or ConsoleColor Color.
In fact, even when in
FullColormode, when outputting escape sequences, we will want to still support the standard^e[0;30;44mstyle combinations for the console colors, so that it's possible to use our module and still get "themed" color outputs as configured in the console preferences. (see the xColors module).