Re: [dev] [dvtm] Truecolor support

From: Marc André Tanner <>
Date: Wed, 29 Oct 2014 12:13:09 +0100

> > Also what does the init_color function actually do then? Does it
> > fall back to a color which best approximates the one given?
> From terminfo(5):
> On a Tektronix-like terminal, the capability ccc may be present
> to indicate that colors can be modified. If so, the initc
> capability will take a color number (0 to colors - 1)and three
> more parameters which describe the color. These three
> parameters default to being interpreted as RGB (Red, Green,
> Blue) values. If the boolean capability hls is present, they
> are instead as HLS (Hue, Lightness, Saturation) indices. The
> ranges are terminal-dependent.
> It modifies the RGB definition of one of the colors of the terminals
> (usually only the first 16 colors, although it can be extended
> until the first 256). The point of true color is you can select any
> color, not only one of a pallete.

Ok as far as I can tell there are two unrelated issues involved (feel
free to correct me):

 1) being able to use many colors (possibly all 2^24) at the same time
 2) being able to set some of the used colors to RGB values

The first is not easily possible with ncurses. As you probably know
curses works based on color pairs. That is before the desired fore
and background color can be used it has to be associated to a color pair
(with init_pair(3)). However pre ABI version 6, or more specificly if
ncurses is not compiled with --enable-ext-colors only 256 color
pairs (= different combinations of fore and background colors) an be
used at the same time.

Therefore dvtm maintains a mapping of (fg,bg) -> color pair. A LRU
strategy is employed to reuse the color pairs.

However I believe the OP wants option 2). This could probably be
achieved by using init_color(3) and maintaining some sort of mapping
from (fg-rgb, bg-rgb) -> color pair. Or probably better using 2 such
mappings (r,g,b) -> color number and (fg, bg) -> color pair.

 Marc André Tanner >< >< GPG key: CF7D56C0
Received on Wed Oct 29 2014 - 12:13:09 CET

This archive was generated by hypermail 2.3.0 : Wed Oct 29 2014 - 12:24:09 CET