[ On Tuesday, August 6, 2002 at 15:55:49 (+0100), Julian Coleman wrote: ]
> Subject: Re: Colour curses programs now default to white on black
>
> > >                  This means that colour curses-using programs will now
> > > display as white on black by default.
> > 
> > White on black?  Do you mean everything will be in reverse video if I
> > normally set my terminal to black letters on a white background?  If so
> > then that's got to be wrong.
> 
> Yes, if the curses program uses colour (i.e. calls start_color()), it will
> display as white on black by default.  To get the terminal default colours,
> the program will need to call use_default_colors().

Hmmm.....  That can't be right.  The terminal default colours should
always be the initial values configured in the terminal by the user (eg.
for xterm with the '-bg' and '-fg' options, etc.) unless the application
explicitly asks for something else.  The _default_ should be exactly the
same as if nothing were done.

>   In order to set the
> colours to arbitrary values, call assume_default_colours(fore, back).
> 
> > The _default_ should be exactly the same as if nothing were done to
> > change the colours used for normal text.  Nothing in the document at the
> > URL you provided says anything about forcing white on black (or reverse
> > video).
> 
> It says :
> 
>      The  start_color()  function  also  restores  the  colours  on  the
>      terminal   to   terminal-specific   initial   values.  The  initial
>      background colour is assumed to be black for all terminals.
> 
> So, I suppose we could have any colour on black.

I think you're making incorrect assumptions.  The text you quote says
that the default initial background colour is "assumed" to be black.  It
does not say that the start_color() function will set the background
colour to be black.  It does not say the foreground colour will be set
at all.

I don't know what your change will do to 'links', but currently it is
_really_ badly misbehaved if you tell it to use color, especially if
you're using xterm -- suddenly everything is white on black even if the
terminal is configured to show black on white by default.  This is very
disconcerting and very unfriendly.

I'm assuming your change won't fix 'links' but will in fact "break"
other applications and make them misbehave in the same way it does.

The default original background colour is not necessarily "black".  It's
whatever the user set it to.  There is no such thing as standard default
foreground colour either.  The "terminal-specific intitial values" are
whatever the user has currently set the terminal to display.  All the
text above says is that it is assumed the user will have chosen black as
the background colour.  I don't have any clue though as to why this
assumption is important -- I suspect it's meaningless.

An ANSI standard terminal (including xterm if I understand things
correctly) can be set to use its default colours by sending the
sequence:  ESC [ 3 9 m ESC [ 4 9 m  (or its shortened form)

The only thing start_color() should do, if it does anything at all, is
to send this sequence.  IIRC in a terminfo based curses implementation
the string given by the 'orig_pair', or 'op' capability would be sent.
According to the SysVR4 manuals this corresponds to the 'op' termcap
capability, but NetBSD's termcap(5) doesn't define that one....

Acutally Some termainals may also need 'oc' to be sent in order to reset
all the color-pairs to their original values too....

BTW, quoting the SysVR4 curs_color(3x) manual page:

	The \f4start_color\fP routine requires no arguments.
	It must be called if the programmer wants to use colors,
	and before any other color manipulation routine is called.
	It is good practice to call this routine right after \f4initscr\fP.
	\f4start_color\fP initializes eight basic colors
	(black, red, green, yellow, blue, magenta, cyan, and white),
	and two global variables, \f4COLORS\fP and \f4COLOR_PAIRS\fP
	(respectively defining the maximum number of colors and color-pairs
	the terminal can support).
	It also restores the colors on the terminal to the values they had
	when the terminal was just turned on.

Note in particular the last sentence.

Perhaps your confusion stems from the strange xterm confusion where with
16-colour support disabled the sequence "ESC [ 1 0 0 m" will set the
foreground and background colour to their default (i.e. command-line
specified) values, but with 16-colour support enabled that same sequence
will just set the background colour to black.  The original 'xtermc'
entry in the SysVR4 terminfo database gives "op=\E[100m", but that was
from xterm.ti revision 1.3, which was long before xterm ever had full
16-colour support.

If you look in NetBSD's xsrc/xc/programs/xterm/terminfo you'll find that
'op' is now (correctly) defined as "\E[39;49m".  Indeed the 'termcap'
file in the same directory also defines an 'op' termcap capability with
the same sequence.

Maybe NetBSD's termcap(5) needs to learn 'op', 'oc', et al too, and of
course start_color() should send thos strings, not set white on black or
any other specific colours.

>  White seemed best.

That's about the only thing I can agree with!  ;-) but it's irrelevant
since start_color() shouldn't be setting any arbitrary colours, but
rather only reset the terminal to those which the user has initially
configured it to display.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>