On Sat, Nov 19, 2005 at 07:02:25PM -0500, Thomas Dickey wrote:
> On Tue, Nov 01, 2005 at 03:50:07AM +0100, Ron wrote:
> ...
> > I was poking at the use of terminal default colours today and
> > ran into what looks like a bug in assume_default_colors.
> >
> > If it is called with neither of its arguments as -1, then
> > SP->_default_color is set to be false, and consequently
> > any attempt to use init_pair to define a color pair using
> > -1 to get the terminal default will fail.
>
> Looking at the change history, I see that I did this intentionally,
> so that
>
> assume_default_colors(COLOR_WHITE, COLOR_BLACK);
>
> would disable the feature. In retrospect, that's to compensate for
> not providing a parameter to use_default_colors(). If I had added
> both functions at the same time, that probably would have occurred
> to me. But they were a few years apart.
>
> I could add a new function to do that (though it wouldn't be as nice
> since "use_XXX" is consistent with use_env(), etc). It's possible that
> changing the function would cause some applications to give different
> results.
Ok. So we can't change the existing api without an SONAME
change then -- adding a flag to use_default_colors will break
things that expect its signature for a symbol, and changing
the semantics of assume_default_colors will change intended
(even if not documented widely) behaviour and silently change
at least some existing apps in uncertain ways.
Which I guess means the best option must be something like:
/* The names of these two are up for grabs,
if better ones are known ... */
int use_term_colors(bool f);
int set_term_colors(int,int);
/* then redefine existing functions,
(maybe deprecate them for later removal?) */
int use_default_colors()
{
return use_term_colors(TRUE);
}
int assume_default_colors(int fg, int bg)
{
if( fg == COLOR_WHITE && bg == COLOR_BLACK )
return use_term_colors(FALSE);
return set_term_colors( fg, bg );
}
As we can test for the ncurses version that supplies the new symbols
and use them if available, while old apps should not be affected if
they are relinked unchanged to a new ncurses.
It would probably be nice if use_term_colors always respected
the last colours set by set_term_colors when f = TRUE, even if
it still needs to fetch the '-1' COLOR the first time and store
them for other/later uses. ie. so that:
set_term_colors( myfg, mybg );
...
use_term_colors(TRUE);
...
init_pair(1, COLOR_WHITE, -1);
will always work the same, whether the initial state was that
use_term_colors() had been called with TRUE or FALSE, or had
never been called at all... but I fall quickly out of my
depth on the finer implementation details in there so I'll
stop heading down that track for now.
API wise, I might also request that we:
#define COLOR_DEFAULT -1
before lots of other people fill the region of that namespace
with minor variations of their own ;-)
Another name would be fine there too, but I would like to
have a slightly more 'symbolic' symbol for that purpose.
Anyway, how does that lot look from other angles?
cheers,
Ron
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
