|
I think there might be some confusion
here.
Firstly, no, you can't exceed COLORS.
If your terminal emulator wants to support direct-color mode when
the outer terminal is 256-color, you'll just have to round each
color to the nearest entry in the 256-color palette, like tmux
does. Just because *your* 256-color terminal happens to also
support direct-color mode doesn't mean that every 256-color
terminal does.
Secondly, xterm-direct operates very
differently from traditional paletted-color modes like
xterm-256color, and your code probably won't handle it properly
unless you manually update it. For example, xterm-direct cannot
modify its "palette"; if you want to draw text in colour #AABBCC,
you can't call init_color() or init_extended_color(), you just
create a pair and pass it color 0xAABBCC (assuming 24-bit
direct-color, see the "RGB" capability in user_caps(5) for
details). See this previous thread for direct-color details:
https://lists.gnu.org/archive/html/bug-ncurses/2018-04/msg00011.html
On 31/1/20 3:15 am, Bryan Christ wrote:
Thomas,
So I'm a bit more confused now. I am using
extended_color_content() and as soon as "int color" is >
255 the function returns ERR. I did a simple test with
"xterm-direct" and it still doesn't matter. The debug code
snippet in question is this:
retval = extended_color_content(color, r, g, b);
if(retval == ERR) { endwin(); fprintf(stderr, "gc %d\n\r",
color); exit(0); }
As soon as the variable "color" becomes 256 it fails
returning ERR. It's behavior seems identical to what is
described for the standard color_content() API for which the
man pages says:
The
first argument must be a legal color value, i.e., 0
through COLORS-1, inclusive.
The man pages really don't say anything about
extended_color_content() other than it uses int instead of
short. So why is it rejecting a color value of 256 even when
TERM is set to xterm-direct?
I am encountering this with the distro included version of
ncurses on Fedora 31.
On
Wed, Jan 29, 2020 at 03:21:21PM -0600, Bryan Christ wrote:
> When ncurses starts up, I know that it looks at the value
of "colors" from
> the terminfo entry and sets COLORS accordingly. However,
I also know that
> the underlying terminal supports way more colors and
pairs than is
> advertised by the terminfo entry. Is there a way to
forcibly exceed that
> limit? The following script runs great on the native
terminal, but as soon
> as I run in my emulator, under the confines of ncurses, I
hit a 256 color
> wall.
>
> !/bin/bash
> awk 'BEGIN{
> s="/\\/\\/\\/\\/\\"; s=s s s s s s s s;
> for (colnum = 0; colnum<77; colnum++) {
> r = 255-(colnum*255/76);
> g = (colnum*510/76);
> b = (colnum*255/76);
> if (g>255) g = 510-g;
> printf "\033[48;2;%d;%d;%dm", r,g,b;
> printf "\033[38;2;%d;%d;%dm", 255-r,255-g,255-b;
> printf "%s\033[0m", substr(s,colnum+1,1);
> }
> printf "\n";
> }'
I suspect the issue to resolve is in your emulator - ncurses
6.1 can
_show_ 2^24 colors using the xterm-direct terminal
description
(though it requires some work to map to/from the different
representations),
but it won't show 2^24 colors using xterm-256color
Using the full range of colors requires the *_extended
functions,
as I did in picsmap:
https://github.com/ThomasDickey/ncurses-snapshots/blob/master/test/picsmap.c
e.g., these
extern NCURSES_EXPORT(int) init_extended_color(int, int, int,
int);
extern NCURSES_EXPORT(int) init_extended_pair(int, int, int);
and the functions where an "opts" parameter was reserved to be
null:
https://invisible-island.net/ncurses/man/curs_attr.3x.html
--
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net
--
Bryan
<><
|