我正在开发一个基于 urwid 的带有文本模式 GUI 的 python 程序。urwid 是一个使用 python 创建 ncurses 风格程序的库。
操作系统是CentOS 7。
在“正常”条件下(X-Server、终端窗口),一切都运行正常。但是,在没有 X-Server 的 Linux 控制台上,urwid 会切换到低色模式。(在某些机器上,如果颜色代码错误,我会看到令人烦恼的闪烁文本)
有趣的是,仍然使用 Linux 控制台,我只需要启动屏幕作为解决方法。屏幕内部一切正常。无需对屏幕进行任何特殊配置。
我已经尝试比较纯文本 shell 和屏幕 shell 之间的大量环境信息,但这没有帮助。例如,语言环境相同,python 的 sys.stdout.encoding 相同,在 vim 中执行“:runtime syntax/colortest.vim”在两种情况下看起来都是正确的,而且色彩丰富。
答案1
这是正常的。发生这种情况只是因为 Linux 内核控制台不支持256 色模式。它不是为使用 256 种颜色而编写的,就像VGA 文本模式根本没办法做到这一点。(在帧缓冲模式下可以,但代码仍然有完全相同的限制。)GNU Screen 知道这一点,并自动将 256 色调色板转换为最接近的 16 色调色板。
仅限最新的 Linux 版本(3.13 及更高版本)开始认识256 色转义码,但即便如此,它仍然像 Screen 一样将它们映射到 16 色调色板。
有基于帧缓冲区的终端模拟器,例如康或者术语表它们实现自己的渲染,并通过 KMS 绘制所有内容。如果您想要一个能够避免使用 X11 的终端,请使用它们。
文本闪烁是因为 256 色代码很容易与 16 色代码混淆。例如,ESC [38;5;35m
可以解释为 256 色代码,或三个 ANSI(16 色)代码。
Linux 控制台不知道这是什么
38
意思,所以它只是以通常的方式将其解释5
为“启用闪烁”和“前景 - 颜色#5(洋红色)”。35
(例如参见这张桌子,在“SGR”下。)同时,您的 X11 终端将其识别
38
为神奇的“前景 - 额外颜色”代码,因此它们将其解释5
为“使用 256 色调色板”和35
“使用颜色 #35(青色)”。
(还有 24 位 RGB 模式ESC [38;2;<r>;<g>;<b>m
。)