Konsole supports true colors, however, there's no official way of advertising this feature. Unfortunately the maintainer of ncurses and terminfo is not interested at all in adding this possibility to terminfo, see e.g. https://lists.gnu.org/archive/html/bug-ncurses/2016-08/msg00036.html. S-Lang, on the other hand, has just released its version 2.3.1 with true color support. Due to the lack of an "official" way of checking for this feature, the author decided to look at the COLORTERM environment variable expecting it to be set to either "truecolor" or "24bit". See http://lists.jedsoft.org/lists/slang-users/2016/0000014.html. The probably most well-known application using S-Lang (by default, with ncurses being an option too) is Midnight Commander. It has a patch on its way to support true colors, see https://www.midnight-commander.org/ticket/3145. VTE (gnome-terminal et al) sets this environment variable beginning with version 0.44, see https://bugzilla.gnome.org/show_bug.cgi?id=754521. Please make konsole set this variable. This is required for a forthcoming version of Midnight Commander to support true colors out of the box without any kind of hacking. Also, being consistent across terminal emulators is the best we could do to make this a de facto standard and encourage the authors of other applications that support true colors to also check for this environment variable rather than everyone coming up with their own individual hacks.
Just FYI: iTerm2 counterpart filed at https://gitlab.com/gnachman/iterm2/issues/5294.
So you want it added to the environment like TERM=term? You can do that manually by Profile->Environment (COLORTERM=truecolor). I assume you want it by default?
Yup, I'm asking to add it by default so that users get true color support in mc out of the box in a couple of months from now, and developers of other apps also see this as the pattern to be continued.
Git commit 8c7f165ed6fe1b72e5dfecd1ab24deaddedf9fd6 by Kurt Hindenburg. Committed on 19/11/2016 at 19:39. Pushed by hindenburg into branch 'master'. Add COLORTERM=truecolor to the environment M +1 -1 src/Profile.cpp http://commits.kde.org/konsole/8c7f165ed6fe1b72e5dfecd1ab24deaddedf9fd6
Thanks for your patch! Reopening for some more discussion: Your patch just made me realize that konsole doesn't even advertise 256-color support (TERM is set to xterm rather than xterm-256color). With this patch, it still doesn't advertise support for the pretty widespread 256-color feature, yet it advertises the less common true colors. This doesn't make too much sense to me. S-lang also seems to obey these pieces of information, and refuses to use the 256-color palette, yet allows true colors. Strictly speaking, these are two orthogonal features, and theoretically there could exist a terminal emulator that supports RGB but not the 256-color palette (although I'd be really surprised if it turned out that there exists/existed/will ever exist one). So one can kinda defend this behavior, we could leave konsole as-is, and I could modify the Midnight Commander patch accordingly. In practice, since the true color feature is getting more and more popular because 256 colors is not enough for some people, I'd say it's more practical to think about it as the true color being something that might be implemented, but only after you've got the 256-color palette anyways. MC's current implementation also does this, it has a sanity check for 256-color support according to terminfo before allowing true colors subject to COLORTERM, and it's expected that if a skin definition mentions the usage of true colors then 256-colors are allowed too. So the question is: Which direction do you think is the better? Have you already considered, or could you please consider switching the default to xterm-256color? That would simplify this situation a lot, actually we could just ignore this problem. Has this perhaps been already discussed and rejected for a reason? I found bug 212145 which seems to got forgotten, maybe time to revive? (Just FYI: gnome-terminal changed the default to xterm-256color in vte-0.40, released in March 2015.) Thanks!
Just occurred to me: _if_ terminfo's maintainer wasn't so much against true colors, support would I guess be added in a way that the existing "tput colors" reported 16 million. That is, it wouldn't have the concept of two orthogonal features, rather than just one parameter set to 8, 16, 88, 256 or 16M. In other words, I think it would make 256-color support a prerequisite for 16M.
Git commit 8d32afabb564ae124e06e233be5c5300da906aea by Kurt Hindenburg. Committed on 24/11/2016 at 14:41. Pushed by hindenburg into branch 'Applications/16.12'. Add COLORTERM=truecolor to the environment (cherry picked from commit 8c7f165ed6fe1b72e5dfecd1ab24deaddedf9fd6) M +1 -1 src/Profile.cpp https://commits.kde.org/konsole/8d32afabb564ae124e06e233be5c5300da906aea
Git commit 2671800b084cf89f1a91c6b3fdf93eb3b8078672 by Kurt Hindenburg. Committed on 24/11/2016 at 16:29. Pushed by hindenburg into branch 'master'. set default TERM=xterm-256color Change TERM=xterm to xterm-256color Related: bug 212145 M +1 -1 src/Profile.cpp M +1 -1 src/Pty.cpp https://commits.kde.org/konsole/2671800b084cf89f1a91c6b3fdf93eb3b8078672
Git commit d5cac9d2f1a1225d19c0be6b51e3db6e4aaed3d4 by Kurt Hindenburg. Committed on 24/11/2016 at 16:32. Pushed by hindenburg into branch 'Applications/16.12'. set default TERM=xterm-256color Change TERM=xterm to xterm-256color Related: bug 212145 (cherry picked from commit 2671800b084cf89f1a91c6b3fdf93eb3b8078672) M +1 -1 src/Profile.cpp M +1 -1 src/Pty.cpp https://commits.kde.org/konsole/d5cac9d2f1a1225d19c0be6b51e3db6e4aaed3d4