bug-ncurses
[Top][All Lists]
Advanced

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

Re: init_color() problem


From: Thomas Dickey
Subject: Re: init_color() problem
Date: Wed, 15 Nov 2006 16:26:27 -0500 (EST)

On Wed, 15 Nov 2006, Simon Sasburg wrote:

I recently started fiddling around with ncurses to see if i could use it to
port an MSDOS app of mine to linux.

After finding out I could use A_BOLD to access all 16 colors instead of just
8, i started looking how i could change the palette.

BOLD attribute may display as a brighter color, it may display as a thicker font, it may even be a _different_ color. It depends on the
terminal implementation.  But curses doesn't believe that it's a color,
any more than any of the other video attributes.  (I'd ask what color is
BLINK, but that depends on the terminal implementation ;-)

Now, obviously this is a bit of a hack, and init_color() uses its first
parameter as an index into some array, so it may even cause buffer overflows
or similar nastyness.

yes, that's the way I read the code. It allocates an array within start_colors() and sets COLORS there based on the terminfo entry. Since it's using COLORS thereafter for the array limit, bad things will happen if you increase COLORS.

But, it does work, so the terminal does support changing the rgb values of
the "bold" colors...

I shouldn't really have to use such a hack to make ncurses let me do this, i
think.

You don't - normally that's done in the terminfo description.

You could for instance design an alternate terminfo entry which tells ncurses that the terminal does not support BOLD+color, and alter the setaf/setab strings to use the BOLD attribute as part of their computation.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net




reply via email to

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