Re: Strange behavior with color_content()

[Thomas Dickey]

On Fri, Feb 07, 2020 at 01:15:09PM -0600, Bryan Christ wrote:
> Thomas,
> 
> I've read and reread the content on those links several times now and am
> trying to reconcile with what I see happening with color_content() in my
> own program.  Let me see if I've got this straight:
> 
> 1.  When start_color() is called it initializes the ncurses color table
> with the first "standard' SGR colors (1 - 8, COLOR_BLACK - COLOR_WHITE).

yes

> 2.  When start_color() is called it does not attempt to enumerate any other
> colors in the table and does not attempt in any way, shape, or form, to
> match the underlying terminal palette.

sure.  It cannot do that (portably, at any rate).

> 3.  The terminfo *may* describe RGB encoding in the "initc" extended term
> attribute and nurses will based RGB distribution on that.

yes

> 4.  Assuming the underlying terminal can support it, init_color() will
> define a custom color in the ncurses color table and make the corresponding
> change to the underlying terminal.

yes

> 5.  When color_content() is called, there is no guarantee that it will be
> accurate.

yes

> If I have overlooked any key points please let me know.  It seems like the
> punchline is that if I want a guaranteed behavior from color_content() the
> I will have to initialize my own palette.  Is that a fair statement?

yes/no.  There's no point in initializing the palette if it's already
what you want.

In the ncurses examples, I have sample palettes which are used in a few
places to set the assumed colors.

ncurses.c
picsmap.c
        -p option

loads a palette known to the application (which ncurses doesn't know
about).  Basically the idea is that ncurses will tell you color content,
but doesn't know the correct value if it hasn't been told.  But ncurses
doesn't have to know the color content to update the screen with a given
color number.

linux-color.dat
xterm-16color.dat
xterm-256color.dat
xterm-88color.dat

There's an xterm-specific way to query colors, but it's slow
(and since other terminals which you may have in mind implement
at most only a part of that, a portable solution is _very_ slow).

So... having the application "know" a palette and tell ncurses
which color (number) to use is the way things work for the present.
 
> On Wed, Feb 5, 2020 at 7:39 PM Thomas Dickey <address@hidden> wrote:
> 
> > On Wed, Feb 05, 2020 at 12:05:43PM -0600, Bryan Christ wrote:
> > > In order to find an unused color in the ncurses palette, I run a simple
> > > loop test looking for a free color.  The code is basically something like
> > > this:
> > >
> > > color_num = COLOR_WHITE + 1;    // skip built-in colors
> > > for(;;)
> > > {
> > >     color_content(color_num, &r, &g, &b);
> > >
> > >     if((r + g + b) == 0) break;
> > >
> > >     color_num++;
> > > }
> > >
> > > Now the odd thing is that this works except when the value of "color_num"
> > > is a multiple of 8.  When "color_num" is a multiple of 8, it incorrectly
> >
> > if the special capability RGB is set, ncurses can make useful assumptions
> > about the color content.  If it's not set, ncurses can only assume ANSI
> > color palette (8 colors).
> >
> > RGB is documented in user_caps:
> >
> > https://invisible-island.net/ncurses/man/user_caps.5.html
> >
> > For the latter,
> > that's in the curs_color manual page,
> > in the discussion of start_color:
> >
> > https://invisible-island.net/ncurses/man/curs_color.3x.html#h3-start_color
> >
> > --
> > Thomas E. Dickey <address@hidden>
> > https://invisible-island.net
> > ftp://ftp.invisible-island.net
> >
> 
> 
> -- 
> Bryan
> <><

-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature