|
From: | Bryan Christ |
Subject: | Re: Exceeding COLORS |
Date: | Fri, 31 Jan 2020 12:43:50 -0600 |
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 5:53 PM Thomas Dickey <address@hidden> wrote:
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
<><
[Prev in Thread] | Current Thread | [Next in Thread] |