bug-ncurses
[Top][All Lists]
Advanced

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

Re: Obtaining and setting RGB values


From: Thomas Dickey
Subject: Re: Obtaining and setting RGB values
Date: Thu, 29 Oct 2009 05:34:11 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

On Wed, Oct 28, 2009 at 03:42:00PM -0400, Markus Mottl wrote:
> Hi,
> 
> we are a little confused about the behavior of ncurses wrt. obtaining
> and setting RGB values when the terminal supports 256 colors.
> 
> The function color_content returns bogus patterns for any color larger
> than the standard eight system colors.  This is obviously intended by
> the implementation, but we are not sure why, since we do not know much
> about low-level terminal stuff.  Maybe it's impossible to query terminals
> for these values?

It's generally impossible to query terminals for these values.
ncurses initializes its notion of the values without asking.

It's possible to ask xterm, but iirc none of the other terminal programs that
claim to "emulate" xterm provide this feature.
Even as an experimental feature, that's likely to be slow,
but for the sake of discussion, a demonstration could be constructed.

Also, _setting_ the palette is generally unimplemented
(rxvt is an exception).

> This problem wouldn't be too bad if we could just enforce a set
> of RGB-values.  Sadly, even though ncurses reports that setting of
> RGB-values is supported, there seems to be no effect when doing so.
> 
> Your "ncurses" test application also fails at the above.  The only

When I test that (ncurses with 256 colors), I use one of the palette
files such as xterm-88color.dat to initialize it, e.g., (using TERM
set to xterm-88color):

        ncurses -p xterm-88color.dat

I could add a xterm-256color.dat file, but don't believe it would malfunction
if xterm-88color.dat is working, and other than that the test screen would
be much longer, probably wouldn't see any difference.

> workaround for these problems we have found so far is to implement
> an algorithm that computes the RGB-values associated with the "color
> cubes" and gray scale ramp for 256 colors (tested successfully with
> gnome-terminal and xterm), and to map user-supplied RGB-values to the
> closest available match using some color distance heuristics.
> 
> It also seems that the number of supported color pairs is smaller than
> reported by ncurses (256 (?) instead of 32768).

In INSTALL, I documented the configure option to support extended colors:

    --enable-ext-colors
        Extend the cchar_t structure to allow more than 16 colors to be
        encoded.  This applies only to the wide-character (--enable-widec)
        configuration.

        NOTE:  using this option will make libraries which are not binary-
        compatible with libncursesw 5.4.  None of the interfaces change, but
        applications which have an array of cchar_t's must be recompiled.

That works for 32767 pairs (which is limited by the use of signed-short for
numbers in terminfo data).  65536 would be best, 65535 might be doable
but would require some juggling (so far, not an issue).

> We have tried the newest ncurses release, compiled it with the required
> flags for supporting 256 colors, used different terminals under Linux
> and Mac OS X (xterm, gnome-terminal, rxvt, iTerm) with different
> TERM-settings, etc., but querying and setting colors is obviously
> impossible in any configuration.
> 
> Maybe we are just mistaken about the state of 256 color support in
> ncurses.  Could you please explain whether these are known issues or
> whether there is anything we could try to improve this situation?  Thanks!
> 
> Best regards,
> Markus
> 
> -- 
> Markus Mottl     Jane St. Capital, LLC     address@hidden
> 
> 
> _______________________________________________
> Bug-ncurses mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-ncurses

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

Attachment: signature.asc
Description: Digital signature


reply via email to

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