Hi,
>>
>> There is no support for true color in terminfo, so curses cannot
>> handle it.
>
> Is this a fundamental limitation or just a lack of standardization?
>
> https://lists.gnu.org/archive/html/bug-ncurses/2013-10/msg00007.html
Mainly lack of standardization (this feature was added to terminals in
the last 2/3 years), but as you can read in the thread you posted (I
didn't know it), there are also other problems, because terminfo
definitions uses 16 bit integers.
> 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.
>> If your application need it the only way is to print
>> directly the sequences, and the only way to detect if the terminal
>> has this capability is to check TERM against a list of terminals
>> that suppor it.
>
> Well this sucks. How would you detect old version of these terminals
> which do not yet have support built in? The whole point of
> terminfo/curses is to abstract away these ugly details.
Yes, the problem I can see here is who is going to define this new
capability. This is the problem of moderm unixes. There is a
similar problem with w3m-image, that has a hack that only works
with xterm and fb because it detect them.
Received on Mon Oct 27 2014 - 19:29:23 CET