By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,695 Members | 1,054 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,695 IT Pros & Developers. It's quick & easy.

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

P: n/a
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:
Jul 18 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.