dynamic or on-the-fly color changing in curses?
Matt Garman
fake at not-real.bogus
Tue Nov 2 16:43:13 EST 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?
Thanks,
Matt
--
Matt Garman
email at: http://raw-sewage.net/index.php?file=email
More information about the Python-list
mailing list