[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Usage of of init_extended_color
Roger Pau Monné
Re: Usage of of init_extended_color
Mon, 19 Mar 2018 10:40:57 +0000
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:
>> 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
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:
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.