bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange behavior with color_content()


From: Tim Allen
Subject: Re: Strange behavior with color_content()
Date: Sat, 8 Feb 2020 13:43:45 +1100

On Fri, Feb 07, 2020 at 01:15:09PM -0600, Bryan Christ wrote:
> 5.  When color_content() is called, there is no guarantee that it will be
> accurate.

It will be accurate if you're asking for the content of a color
previously defined with init_color(), or if you happen to be using a
direct-color terminal variant like xterm-direct (in practice, I think
nobody uses direct-color variants yet).

There are escape codes to query a terminal for its current palette, but
they're not described by terminfo (so far as I can tell), and I don't
know how widely supported they are in actual terminals. I think they're
also pretty slow, too.

> 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?

There are somewhat-common terminals that do not support custom palettes,
so init_color() can't be used. For example, the QTerminal widget (that
powers KDE's Konsole emulator), and tmux (unless tmux's outer terminal
advertises the non-standard `Tc` terminfo capability).

In practice, every terminal that supports more than 16 colors defaults
to the xterm 256-color palette. I think most applications ignore
color_content() and maintain their own color cache with different
defaults.

I wonder if ncurses should add another custom terminfo string for
"default palette", so color_content() can be more reliable.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]