Support for RGB Colors about ftxui HOT 3 CLOSED

Thanks for this suggestion!

I would be happy to receive pull request for this feature.
Before starting, do we have a way to check if the current terminal support 16colors/256colors/16Mcolors?
I would suggest reading: https://gist.github.com/XVilka/8346728.
Maybe proceeding like this:

• Checking the env variable $COLORTERM (truecolor => 256
• [fallback] Checking the environment variable $TERM if it contains "256.
• [fallback] Use 16colors.

Alternatively, maybe we can try to read the terminfo?
https://invisible-island.net/ncurses/man/terminfo.5.html

Ideally:

• On terminal not configured for 256colors, it should fallback gracefully by selecting the closest 16colors.
• The new API should preserve compatibility with the current FTXUI version.
• Be cross-platform?

from ftxui.

Cool I'll start working on it then ! Not sure how long it will take me though. It will depend on how much free time I have in the upcoming days/weeks.

Thanks for the links ! I'll take a look and test how we can check color support on terminals.

About the last three points :

• On terminal not configured for 256colors, it should fallback gracefully by selecting the closest 16colors. Since one can override the 16 basic colors of the terminal we'll need to check whether we can get the correct rgb color code from the terminal. Also, the part in the link you sent (https://gist.github.com/XVilka/8346728#terminals-that-parse-ansi-color-sequences-but-approximate-them-to-256-palette) about color approximation and how the correct formula could be performance intensive worries me a little.
• The new API should preserve compatibility with the current FTXUI version. I'm not sure how it could be 100% compatible without becoming a little less clear. If we consider the case where someone was casting an int into a Color enum I'm not sure the API could be compatible without keeping the old color enum around and overriding the operator=. That's not necessarily a problem but having a Color enum and an RGBColor(or some other name) class could be confusing.
• Be cross-platform I only have a linux at home but I was planning to test it on various terminals. Do you have a list of terminals you regularly test on ?

from ftxui.

Also, the part in the link you sent (https://gist.github.com/XVilka/8346728#terminals-that-parse-ansi-color-sequences-but-approximate-them-to-256-palette) about color approximation and how the correct formula could be performance intensive worries me a little.

Let's see first how it goes without optimization, if there are performance issues, we can still install a tiny cache to this function.

• The new API should preserve compatibility with the current FTXUI version. I'm not sure how it could be 100% compatible without becoming a little less clear. If we consider the case where someone was casting an int into a Color enum I'm not sure the API could be compatible without keeping the old color enum around and overriding the operator=. That's not necessarily a problem but having a Color enum and an RGBColor(or some other name) class could be confusing.

An int shouldn't have been casted into the enum class. If someone did this, they will be broken by their fault. This won't be an issue for us.

I think the enum class can be transformed into a class with an enum.

class Color {
  // The 16 standard colors
  enum Enumerated {
     
  }

  Color(Enumated) // Implicit constructor to transform Color::Enumated into Color.
  static Color RGB(int r, int g, int b)
}

This way, people will still be able to use Color::Red, but also Color::RGB(255,0,0)

• Be cross-platform I only have a linux at home but I was planning to test it on various terminals. Do you have a list of terminals you regularly test on ?

Let's say Windows will fallback on 16 colors initially.

from ftxui.