ncurses 65536颜色对
我已经用 - enable-ext-colors
and - enable-widec
flags编译了Ncurses 6.3。
然后,我遍及所有背景颜色,对于每种前景颜色:
void initColorPairs()
{
for (int foregroundId = 0; foregroundId < 255; foregroundId++)
{
for (int backgroundId = 0; backgroundId < 255; backgroundId++)
{
init_extended_pair(
getColorPairId(foregroundId, backgroundId),
foregroundId,
backgroundId);
}
}
};
将Macro Color_pairs设置为65536。
...
std::cout << "initialized color pairs: " << COLOR_PAIRS << std::endl; //displays `initialized color pairs: 65536`
...
这可以很好地工作。
我对此功能定义的每个颜色对都有一个唯一的ID:
int getColorPairId(int foregroundId, int backgroundId)
{
return foregroundId + (backgroundId << 8);
};
这一切似乎都可以很好地工作。 但是,当试图渲染每种可能的颜色对并彼此之间打印它们时:
// visualize
std::string testText = "a";
for (int foregroundId = 0; foregroundId < 255; foregroundId++)
{
for (int backgroundId = 0; backgroundId < 255; backgroundId++)
{
attr_on(COLOR_PAIR(getColorPairId(foregroundId, backgroundId)), NULL);
mvprintw(foregroundId, backgroundId, testText.c_str());
}
}
而不是将每个前景颜色的屏幕上的每个背景颜色都放在每个背景颜色上,我最终得到了:
它应该用每个字符改变背景颜色,但似乎只会改变前景。
奇怪的是,如果Colorid结构被逆转(前景在8位而不是背景上移动),则 background 迭代而不是前景!
int getColorPairId(int foregroundId, int backgroundId)
{
return backgroundId + (foregroundId << 8);
};
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
不使用库接口中的扩展颜色,颜色对仅限于32767(签名16位编号)。
:
如 Extensions 手册页的部分
但是在扩展答案时,我看到这些调用被忽略了(可能是因为颜色对不是这些呼叫的明确参数,而是函数正文内的派生值):
The ncurses-examples (demo and test-programs) include a few using
attr_on
(see:
宏是在其他功能中使用的(允许使用/没有功能的有条件地编译它们) :
对于
wattr_on.c
,块(从属性参数中提取颜色对)看起来像
wattr_set
可以正确处理:(wattr_off
不需要更改, 当然)。 X/Open Curses假设wattr_on
的属性参数opts
参数提供了使用 - ncurses是一致的。Without using the extended colors in the library interface, color pairs are limited to 32767 (signed 16-bit numbers).
That
NULL
inshould be used to pass the value of an integer (more than 16-bits) for the color pair, as mentioned in the Extensions section of the manual page, e.g.,
But in expanding the answer, I see that these calls are overlooked (probably because the color-pair is not an explicit parameter to these, but is a derived value within the body of the function):
The ncurses-examples (demo and test-programs) include a few using
attr_on
(seeREADME
), but those calls aren't using this particular extension (dots_xcurses
would be a good place to do that – optionally of course).picsmap
uses the feature viasetcchar
:wattr_on
setcchar
, using the macroset_extended_pair
That macro is used in other functions (to allow those to be conditionally compiled with/without the feature):
For
wattr_on.c
, the chunk(which extracts a color pair from the attribute parameter) would look like
wattr_set
is handled properly:(No change would be needed for
wattr_off
, of course). X/Open Curses assumes that the attribute parameterat
ofwattr_on
does not include bits for a color pair. ncurses does do this (because it uses the same layout for the attributes in narrow/wide libraries), so providing a use for theopts
parameter is consistent – for ncurses.