True Colour support in various terminals • Hacker News Board

Re: True Colour support in various terminals

#21

Post by toast0 » Tue, Mar 14, 2017, 3:19 PM UTC

est wrote: post #16

You know I tried to hack to play a gif upon SSH login, /etc/issue.net does not accept ANSI chars, but /etc/motd does. So I mkfifo /etc/motd, use some monkey patched shell commands to stream gif to /etc/motd, tried SSH login, the animation totally works, adjust the sleep you get different speeds. I was totally satisfied with this and logged out of my VPS server. Oh wait.... Since my scripts was not in a loop, so it on…

Isn't motd only displayed on interactive login? You could probably have gotten back in if you did something like ssh foo "sudo rm /etc/motd"

Re: True Colour support in various terminals

#22

Post by ziotom78 » Tue, Mar 14, 2017, 3:20 PM UTC

chipb wrote: post #19

ziotom78 wrote: post #7

What I think is really interesting in this is not the possibility to use 16 millions colors per se, but rather the ability to directly specify the RGB components of the color to use. The current approach used by terminfo and ncurses is to refer to an index within a palette, which has the drawback of giving little guarantees about the final shade of the color. (Look at the color table here [1] for a comparison among d…

Except you can already query/set the color palette to arbitrary RGB values with control sequences (at least with xterm, rxvt-unicode, and I imagine others). As far as I've been able to tell, "truecolor" terminal support is about simultaneous display of a range of colors beyond what fits in a palette. Which, eh...seems a bit much for a terminal.

You're right, but I think that truecolor support is easier to program.

I vividly remember when I wrote DOS programs which used VGA/SVGA graphics in the early 90s; switching from palette-based colors to RGB colors was something I really enjoyed! Back in the 90s, loading a 256 color image that used its own palette into DeluxePaint would change the colors of DP's interface too.

Something similar would happen today under tmux, I think: if two side-by-side panels contain two different programs, and one of them reprograms the palette, the other program would be affected too.

Re: True Colour support in various terminals

#23

Post by nenreme » Tue, Mar 14, 2017, 3:48 PM UTC

ziotom78 wrote: post #20

nenreme wrote: post #17

Earlier quoted context omitted.

citrusui originally asked about DCI-P3 color space, ygra then confused this wider color space with higher bit-depth. Now you want to further confuse everyone by referring to your comment about advantages of 24-bit RGB over paletted colors which is completely irrelevant to the original comment about DCI-P3 color space. DCI-P3 contains colors which are outside of the gamut representable by the 24-bit RGB (which uses sR…

Sorry, it wasn't my intention to hurt you with my comment.

No problem :)

Re: True Colour support in various terminals

#24

Post by cooper12 » Tue, Mar 14, 2017, 5:51 PM UTC

octoploid wrote: post #8

Here is an image printing function for bash/zsh: function img { for image in "$@"; do convert -thumbnail $(tput cols) "$image" txt:- | awk -F '[)(,]' '!/^#/{gsub(/ /,"");printf"\033[48;2;"$8";"$9";"$10"m "}'; echo -e "\e[0;0m"; done ;} Example: http://i.imgur.com/d5RzWAC.png

Just a note that this requires imagemagick.

Re: True Colour support in various terminals

#25

Post by duskwuff » Tue, Mar 14, 2017, 10:12 PM UTC

sevensor wrote: post #18

i336_ wrote: post #15

Earlier quoted context omitted.

Sorry, sure. Emitting colors to terminals is trivial, but ncurses - the dominant text UI library (since the 1980s!) - needs to hold the color information for the "windows" or frames that it maintains for you so that it knows how to repaint things when you switch from one view to the next (eg, if some kind of popup opens and then gets closed, ncurses maintains state about what was underneath so it can redraw it for yo…

This sounds like an opportunity for somebody write a backwards-compatible ncurses replacement in a modern systems language. I promise to try using whichever language manages to do this first.

Or even in C! The (n)curses API is ancient -- it dates back to the early 1980s, and has not changed much since then. We've learned a lot about API design over the last 30+ years; we could do much better today.

Re: True Colour support in various terminals

#26

Post by sevensor » Wed, Mar 15, 2017, 12:42 AM UTC

duskwuff wrote: post #25

sevensor wrote: post #18

Earlier quoted context omitted.

This sounds like an opportunity for somebody write a backwards-compatible ncurses replacement in a modern systems language. I promise to try using whichever language manages to do this first.

Or even in C! The (n)curses API is ancient -- it dates back to the early 1980s, and has not changed much since then. We've learned a lot about API design over the last 30+ years; we could do much better today.

Fair point, and today's C is far from what it was in the '80s! Regardless, this is an excellent project for a programming language shootout --- ncurses is well overdue for a rewrite, and I'd love to see the C++17 partisans take on the Rust fans, the Go-ers, and the C diehards.

Re: True Colour support in various terminals

#27

Post by GTP » Mon, Mar 20, 2017, 6:22 PM UTC

i336_ wrote: post #15

GTP wrote: post #12

Earlier quoted context omitted.

I don't understand the problem, could you please elaborate?

Sorry, sure. Emitting colors to terminals is trivial, but ncurses - the dominant text UI library (since the 1980s!) - needs to hold the color information for the "windows" or frames that it maintains for you so that it knows how to repaint things when you switch from one view to the next (eg, if some kind of popup opens and then gets closed, ncurses maintains state about what was underneath so it can redraw it for yo…

It would be great if ncurses supported more colors, but doesn't exist any other library except ncurses that one could use for cli programs?

Re: True Colour support in various terminals

#28

Post by ziotom78 » Fri, Mar 24, 2017, 8:23 PM UTC

i336_ wrote: post #15

GTP wrote: post #12

Earlier quoted context omitted.

I don't understand the problem, could you please elaborate?

Sorry, sure. Emitting colors to terminals is trivial, but ncurses - the dominant text UI library (since the 1980s!) - needs to hold the color information for the "windows" or frames that it maintains for you so that it knows how to repaint things when you switch from one view to the next (eg, if some kind of popup opens and then gets closed, ncurses maintains state about what was underneath so it can redraw it for yo…

Hi i336_, I believe the problem lies not in the fact that there are only 256 values available in an "unsigned int" (an int is at least 16 bits wide). The point is that ncurses requires to work with color pairs, which encode both the foreground and the background color in an index. This was made in order to preserve compatibility with some old HP terminals that were not able to set the two colors separately (using "setaf" and "setbf", like Tektronix terminals used to do).

The problem with direct color is, if you have N colors, the number of pairs is N^2. When N=2^24, indexing pairs would require a variable of size 48 bits at last, but the current ncurses' ABI doesn't allow this.

I believe that almost every modern terminal doesn't use paired colors anymore, but ncurses has always tried to provide compatibility with a wide set of terminals, and I understand their lack of enthusiasm in supporting this.