in reply to Curses.pm with Term::ANSIColor

I've often found that has_colors() is deficient, and that you can often do better by just looking at $ENV{TERM} and guessing. start_color() doesn't need has_colors() to return true to work -- try writing some test scripts that do initscr(), start_color(), and see what happens, like this:
#!/usr/bin/perl use Curses; my $cid = 12; # Just an arbitrary slot initscr(); start_color(); init_pair($cid, ::COLOR_BLUE, ::COLOR_BLACK); $blbk = COLOR_PAIR($cid); attron($blbk); addstr(0,0,"Hey"); refresh(); sleep(3); endwin();

Replies are listed 'Best First'.
Re: Re: Curses.pm with Term::ANSIColor
by Llew_Llaw_Gyffes (Scribe) on May 07, 2003 at 03:50 UTC
    I'll try this right away, having just gotten Curses.pm patched to build with 5.8 and threading.
      has_colors() is indeed lying. However, Term::ANSIColor still does not work in a curses window, when Curses color does. So I guess I get to rewrite all the color code for the interactive portion of the program to do its colors that way.
        Just so you know, when you activate a Curses "screen", most normal screen I/O won't work right, something that will create problems if, say, your application calls die() or uses any other functions that do screen I/O that don't understand Curses. When writing curses applications, it's usefil to put calls to endwin() right before all your die()s (and of course, before your application exits).