dynamic or on-the-fly color changing in curses?

Matt Garman fake at not-real.bogus
Tue Nov 2 22:43:13 CET 2004

I'd like to write a class or module in python that allows me to do
on-the-fly color changing in the curses module.

I'm thinking about something along the lines of this:

    addstr(y, x, 'hello', brightyellow, blue)

The module would automatically interpret the above as

    curses.init_pair(i, curses.COLOR_YELLOW, curses.COLOR_BLUE)
    addstr(y, x, 'hello', curses.color_pair(i) | curses.A_BOLD)

What I thought I could get away with is constantly redefining the
same color_pair, as in the following:

    curses.init_pair(1, curses.COLOR_RED, curses.COLOR_BLACK)
    scr.addstr(0, 0, 'Hello, world', curses.color_pair(1))

    curses.init_pair(1, curses.COLOR_BLUE, curses.COLOR_BLACK)
    scr.addstr(1, 0, 'Hello, world', curses.color_pair(1))

    curses.init_pair(1, curses.COLOR_GREEN, curses.COLOR_BLACK)
    scr.addstr(2, 0, 'Hello, world', curses.color_pair(1))

But when I do that, all strings show up as green.  My assumption
here is that all strings are assigned to color_pair(1), and when
those strings are drawn, they assume the most recent definition of
color_pair(1).  In other words, it appears you can't "recycle" color
pair definitions.

So my second thought was to just pre-define every possible
combination, but, at least on Linux, I'm limited to 63 unique
colors, whereas I can create more than 63 color combinations
(foreground, background, and attribute combinations).

Am I strictly limited to using at most curses.COLOR_PAIRS colors on
a per-application basis?


Matt Garman
email at: http://raw-sewage.net/index.php?file=email

More information about the Python-list mailing list