Re: Usage of of init_extended_color

[Roger Pau Monné]

Thanks for the answers, I'm replying from my gmail account, since it
seems like the email has bounced from my other account.

On Sun, Mar 18, 2018 at 5:07 PM, Thomas Dickey <address@hidden> wrote:
> On Sun, Mar 18, 2018 at 03:58:21PM +0000, Roger Pau Monné wrote:
>> Hello,
>>
>> I'm looking into modifying a ncurses based application so it can make
>> use of more than the default 256 color xterm palette, but I'm having
>> some issues figuring out how to do that. The terminal I'm using
>> supports truecolor and has COLORTERM=truecolor set in the environment.
>
> hmm - start here
> https://invisible-island.net/ncurses/ncurses-slang.html
> https://invisible-island.net/ncurses/ncurses-slang.html#cause_environ
> https://invisible-island.net/ncurses/ncurses-slang.html#env_COLORTERM

Thanks for the context.

>> I need to keep support for the already existing xterm-256 color
>> palette, so AFAICT the 0..255 color values cannot be modified in order
>> to keep existing users. I though that using the new
>> init_extended_color would allow me to define color values > 255, but
>
> Not exactly.  Essentially you're talking about "indexed color", which
> is different from "direct color" (which some people ironically insist
> on calling "true color").

Right, sorry if some of this is incorrect, I haven't done much
development with curses.

> Indexed color uses a palette, i.e., a set of colors from which you
> can select a particular one using an "index".  The maximum size of the
> palette is implementation-specific.  In theory, that could be "any"
> practical size, but in practice xterm uses 256 because it is convenient
> (and other developers have chosen to copy xterm's behavior rather than
> demonstrating a useful program with a larger palette).

So basically in order to have a bigger palette I should change my
terminal type to something different than xterm-256, hoping there are
implementations out there with palettes bigger than 256. I guess one
could theoretically have a xterm-2^24, with a 2^24 color palette
representing all the possible color values.

> Direct color (again, the sizes are implementation-specific), would
> provide a way to represent the colors in the palette used for indexed
> color, and you _could_ map from indexed-color to direct-color.  But
> ncurses won't do that mapping for you: it's not general enough to
> be useful to more than a small niche, though it's a trivial exercise
> for a developer.
>
> This program does it, for instance:
>
> https://invisible-island.net/ncurses/ncurses-slang.html#compare_picsmap

I've looked into the program, and I have a stupid question, the following macro:

#define Scaled256(n) (NCURSES_COLOR_T) (int)(((n) * 1000.0) / 256)

Is supposed to scale [0..255] values into the [0..1000] range, shouldn't it be:

#define Scaled256(n) (NCURSES_COLOR_T) (int)(((n) * 1000.0) / 255)

So that if n == 255, the result is exactly 1000?

Apart from that, it's my reading of the code that in order to allow a
user to use both the xterm-256 color palette and RGB color values I
would have to do the following:

 - Fetch the current color palette and store the RGB components of
each color index internally.
 - Replace the indexed colors in the palette, either from directly
user-provided RGB or from the internal database if the user is using
indexes from the xterm-256 palette.
 - Use those indexes with init_color_pair.

Ideally what I would like to achieve is to create a color_pair
directly from RGB values, so that I don't have to mess with the color
palette. It would be nice to have something like init_color_pair_rgb
that would take two 24bit values as foreground and background, without
the need to have them indexed.

Roger.