asciinema
Capture original terminal colors
you can get the colors with some console codes.. i wrote an example here https://github.com/oblique/configs/blob/master/.zsh.d/get_term_rgb_color.py screen, tmux, and virtual console do not support this operation.
also some programs can change there colors, for example cmatrixreloaded this is an example how they do it https://github.com/oblique/configs/blob/master/.zshrc#L160 actually see my ncmpcpp() and wicd-curses() functions
I tried your script but I get following error:
~ % get_term_rgb_color.py 1
Traceback (most recent call last):
File "/home/kill/bin/get_term_rgb_color.py", line 30, in <module>
os.write(fd, bytes("\033]4;%d;?\033\\" % int(x), "UTF-8"))
TypeError: str() takes at most 1 argument (2 given)
the script works in python3.
for python2 change the line to: os.write(fd, "\033]4;%d;?\033" % int(x))
I was thinking about sth like this for some time. Thanks for bringing this on. Unfortunatelly this works only under (u)rxvt and xterm. On gnome-terminal, screen, tmux it does not. So it wouldn't be much of use. If there's maybe other (or additional) way to get this info I'd be happy to use it. Or maybe there's some way to get just the info "are we under light fg/dark bg terminal or under dark fg/light bg".
I haven't looked into it... but maybe something from here? (originally form this stackoverflow answer)
It does work in gnome-terminal but it doesn't in konsole. I will try to find any other way.
I found that with tmux you can forward console codes to the terminal and I modified my script https://github.com/oblique/configs/blob/master/.zsh.d/get_term_rgb_color.py I didn't manage to do it with screen. If you have any questions please ask.
Sorry, I forgot to push my changes in ncmpcpp() and wicd-curses() functions, now it's updated.
I just checked it under urxvt, xterm, gnome-terminal and tmux. Only under gnome-terminal it's not working. Do you think this could also work on some OSX terminal like Terminal.app or ITerm2 ?
At the moment I'm refactoring the recorder a little (here: https://github.com/sickill/ascii.io-cli/tree/split). Once I'm done with refactoring I'll try to use the code you provided here.
Thanks!
I don't know about Terminal.app or ITerm2, if they support color changing it will work..
Just for the reference, I have also found this : https://github.com/dranjan/termcolors Not sure if it gives us anything more than the @oblique's code though.
It looks like https://github.com/dranjan/termcolors depends on select.poll, which doesn't seem to work in OSX.
Scratch that, I was wrong. @sigmavirus24 figured out that there was an issue with the tool passing -1*2 around as a timeout value instead of just -1. More investigation needed... but this might end up working.
Also note that when I tried this on OSX+iTerm2 it didn't actually pick up the term colors properly. So even with that fixed, it's still not the most optimal since the underlying C API that termcolors uses (select/select.poll) is not as flexible as the other *nix flavors which will accept any negative value.
So I worked on this with @sigmavirus24 and came up with this: https://gist.github.com/joshuarh/7904813. The following still needs to be done/checked:
- Send the color info up to the server
- Remove the default colors? or use them as a fallback?
- Make sure the background/foreground colors are correct. We're using "magic numbers" here, but I think they're constant, at least for xresources/xdefaults colorschemes.
- Make sure the web player can handle what's recorded.
- I thought I read the player the site uses is vt100 compatible, or something to that effect. So can we send it escape codes and have it "just work"? Or do we need to convert the colors to hex first? If it's the latter, then we have some work to do. I know some colors are laid out with the rgb info right in there, so that's not hard to parse, but mine on urxvt look like this:
'\x1b[30m', so I'm not sure how to convert that to something we can use on the web.
- I thought I read the player the site uses is vt100 compatible, or something to that effect. So can we send it escape codes and have it "just work"? Or do we need to convert the colors to hex first? If it's the latter, then we have some work to do. I know some colors are laid out with the rgb info right in there, so that's not hard to parse, but mine on urxvt look like this:
- Test it in various terminals. I know some of the other solutions didn't work on various terminals (VTE-based ones, Terminal.app, iTerm, rxvt, etc), so we should make sure this works before using it heavily.
It doesn't seem easy to obtain the terminal's colorscheme. Instead, could we allow the user to specify her/his colorscheme in a JSON file ? If the implementation is done generically enough, it'll be a breeze to switch to any new technique to capture the terminal colors we'd discover later on.
It doesn't seem easy, but I'm not convinced that it's not doable. I think we can record the escape codes, we just need to convert those back to xterm colors.
OTOH, if we allowed users to specify which colors they wanted, that brings up interesting possible features and bugs. We could let people choose which scheme they want to see when browsing, but depending on the foreground colors that were recorded, this could be a problem (for instance, here's the default theme with solarized foreground colors in fallback mode: https://asciinema.org/a/2214).
What I really meant is that it should be to the uploader to specify the colorscheme. As to the rest, I don't know and I'm not really able to judge.
@losingkeys we ARE already recording the escape color codes. The thing is they are just single numbers like 1, 2 or 3. They mean red, green and yellow. And so on. People use different color schemes in their terminal but most of the schemes are close to the "original" xterm colors so it looks "ok" in majority of cases.
@losingkeys Allowing the user to specify his color scheme (let's say in .Xresources format) is an easy thing to do and I'm considering doing just that. So if you use solarized or some other terminal theme that completely alters the meaning of each color it's gonna be a solution for wrong colors.
@mrabault the ideal solution would be to use recorder to detect and upload terminal scheme, yeah. But we haven't found (yet!) a good enough solution that would work for majority of terminal emulators across different OSes.
Has there been made progress in this regard, e.g. on the go branch?
Would querying xrdb for colors be an option? This could pick up a custom theme (e.g. solarized) automatically.
@blueyed no progress so far.
Querying xrdb would only make sense for xterm/rxvt/other-terminal-using-x-resources. People use libvte based terms (Gnome Terminal, XFCE Terminal, Terminator,...) and non-Linux terminals (iTerm, Terminal.app on OS X) too.
@blueyed btw, you can change a theme for your asciicasts, either account-wide (on your account settings page) or per asciicast (on asciicast edit page). For ex this is your asciicast in solarized-dark: https://asciinema.org/a/13855?theme=solarized-dark
We're discussing version 2 of asciicast format in #196, and I think adding optional colors object to meta-data, containing text foreground/background color and the palette for all 8(16) colors would be a nice addition. As @mrabault said, we can use and update a technique of obtaining the colors, as long as the palette representation in JSON stays the same/compatible with the web player.
As for the actual technique, this issue is very old one and the linked solutions seem to be gone. I wanted something that works on all platforms, and I was hesitating to settle on non-100% working solution. Now I think it's better to just support what we can now, treat the colors palette as optional, and fallback to player's default theme when it's not in JSON (for any reason).
Anyone with something working on Python 3.3+?
@timofonic please never again just mention literally everyone who has been in contact with a repository. I'm not even a contributor here and I wouldn't have any "news" for you.
As an aside, if anyone had "news" on this - or the other 2 issues you mentioned myself and many others on - it would have been posted here as either a comment or a pull request that closes this issue. If you don't see anything relevant to the issue, assume that there is "no news" for you.
