4 ms·
What I think is really interesting in this is not the possibility to use 16 millions colors per se, but rather the ability to directly specify the RGB component
by ziotom78 10y ago
What I think is really interesting in this is not the possibility to use 16 millions colors per se, but rather the ability to directly specify the RGB components of the color to use.
The current approach used by terminfo and ncurses is to refer to an index within a palette, which has the drawback of giving little guarantees about the final shade of the color. (Look at the color table here [1] for a comparison among different terminals; here it is stated that xterm changed the RGB components of two shades of blue from one version to another!)
Allowing true colors in terminals would make curses programming very similar to what you do in HTML and CSS, where you directly specify the color you want. It would surely be a nice improvement.
[1] https://en.m.wikipedia.org/wiki/ANSI_escape_code https://en.m.wikipedia.org/wiki/ANSI_escape_code
- chipb 10y agoExcept you can already query/set the color palette to arbitrary RGB values with control sequences (at least with xterm, rxvt-unicode, and I imagine others). As far as I've been able to tell, "truecolor" terminal support is about simultaneous display of a range of colors beyond what fits in a palette. Which, eh...seems a bit much for a terminal.
- ziotom78 10y agoYou're right, but I think that truecolor support is easier to program. I vividly remember when I wrote DOS programs which used VGA/SVGA graphics in the early 90s; switching from palette-based colors to RGB colors was something I really enjoyed! Back in the 90s, loading a 256 color image that used its own palette into DeluxePaint would change the colors of DP's interface too. Something similar would happen today under tmux, I think: if two side-by-side panels contain two different programs, and one of them reprograms the palette, the other program would be affected too.