Show HN: Tattoy – a text-based terminal compositor
Firstly it solves the age-old problem of low-contrast text, like when you `ls` a broken symlink and the red background colour is too near your current theme's foreground colour. Tattoy solves this by using none other than the web's WCAG 2.1 contrast algorithm for accessible text.
Secondly, an explicit design goal is that Tattoy should be able to polyfill new terminal protocols, the `xwayland` of the TTY if you will. Say if we want to experiment with completely deprecating ANSI codes, then any application that uses a new protocol can be run in Tattoy which itself runs in any ANSI-standard terminal emulator as normal. You can read more about this idea here: https://tattoy.sh/news/an-end-to-terminal-ansi-codes/
But ultimately this has been something more akin to an art project, something to enjoy for the sheer aesthetic pleasure.
So far it was able to take the screenshot correctly (https://ibin.co/8kaRr8TIanv2.png), however the parsing of that fails with the non-descript "Palette parsing failed." error.
Edit: enabled tracing at got this: https://paste.ee/p/ZyNxG9FK
A better way to do this is to send `OSC 1 0 ; ? ST` (query foreground color), `OSC 1 1 ; ? ST` (background color), then `OSC 4 ; {n} ; ? ST` where {n} is the nth XTerm color.
See: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h4-O...
https://github.com/tattoy-org/tattoy/issues/42
So, it is supported or not? Looks great by the way.
Windows is supported, I've tested it in Windows Terminal and Powershell. I removed it that issue from the release plan because not all the subtasks are finished yet. And more broadly speaking I just haven't had much feedback from Windows users. For example I haven't managed to get GPU passthrough working in my Windows VM so haven't actually been able to test shaders yet.
this raises two questions: doesn't every (gui) terminal do that?
what happens if i use tmux inside tattoy?
btw: do you have examples of light themes?
Interestingly Alacritty in the beginning didn't natively support scrollback because it wanted to hand-off that concern to multiplexers like tmux. So there's precedent for terminals emulators not having to support scrollback.
tmux should work fine in Tattoy, the only thing to be aware of is that Tattoy would then handle input, like for scrolling etc, so some events may not reach tmux, in which case you could make some custom tmux keybindings that Tattoy doesn't recognise. It's also worth noting that Tattoy recognises the so-called "alternate screen" state that tmux controls its host with. And in such cases Tattoy forwards scrolling events to the underlying process, like say the mouse scroll wheel.
I don't have any light theme examples yet. It should mostly just work though.
what i was wondering is how the scrollback of tattoy and tmux would interact. normally when you use tmux the terminals scrollback remains unused (which is why alacritty devs thought they don't need their own). but from how tattoy uses the scrollback, i feared that tmux would actually interfere with some tattoy functionality. that's what i am curious about.
I also have some ideas to make Tattoy into a multiplexer. I really like the idea of desaturating and fading unfocussed panes.
A couple of points related to contrast ratio management:
- The Mynex answer here is very informative: https://stackoverflow.com/questions/596216/formula-to-determ...
- The "limit/bound" on the contrast ratio has a "polarity" (a +- sense). At least for "text", in almost every font there are many more background pixels than foreground pixels. So, for example, your human eyes can tolerate a lower text cell fg-bg contrast with a dark background color for the text cell on an all-black background than they can for a dark foreground color on an all-black background. Part of this relates to "shared discrimination work" that the outside-the-text cell background pixels are doing. So, really "ratio" of just two things is somewhat of an oversimplification.
- XTerm OSC 4 may have a very limited ability to probe the color palette. At least on `st` I can only see default foreground, background and cursor colors, not the full 16-color palette. This mostly just amplifies the point elsethread by @hnlmorg.
- At least until more recent ssh's, default configs on Linux would pass through all "LC_*" environment variables. So, if you adjust your shell rc/configs to key off of, say, $LC_THEME having, e.g., "light" or "dark" in them, you can perhaps re-polarize everything with a much lower tech solution. I do this all the time as I like to run some terminals with a black background and some with a white background. (Paper white black & white displays were all the rage in the 90s, but these days "color hackers" seem to prefer dark backgrounds. I have theories as to why, but it's pretty off topic.) https://github.com/c-blake/lc configs have more fully fleshed out examples, and hey, you might also like that color-ls. (And I'm aware of the ancient & to my mind ugly 1980s ideas of "stuff everything into $TERM and parse it apart again". Security concerns may push us back that way.)
What st version? For me, 0.9.2 prints the entire color cube with
(although unsurprisingly, it's subtly broken: I sent ST, but the responses are terminated with BEL...)Thank you for correcting the record, @shiomiru!
I'm thinking that I'm going to support both palette screenshotting and OSC 4.
I've certainly seen those LC_* variables before but I don't seem to have them right now in my current shell. Are you saying that they can be another source of the true colour values of the palette indexes?
The screenshotting is surely more portable.
I was not saying LC_* are a source of color values, though a terminal could surely do that as a way to export this data to its first shell without the clunky stdin/out protocols for OSC4. For example, I believe one variant of rxvt/urxvt used to export COLORFGBG. I would even say (LC_FG LC_BG LC_COLOR0..15 LC_CURSOR, etc) is an ok idea. One downside is a user could change the values since environment variables are very much not "read only", but that is sort of "on them" for fooling subprocesses "on purpose".
I was mostly lamenting that ssh server configs are moving toward making it hard(er) to "pass through" this kind of environment variable-driven setup. Something people often overlook in this general problem space is making whatever protocol they come up with also "work through to shells beyond one (or more) ssh hops". So, the LC_COLOR<N> idea would have been "more fabulous" 5..10 years ago when I would have anticipated "this will usually work". Maybe it could still be easier for some than OSC4.
Anyway, big topic with half century of history and hard to be brief.
I kind of like that idea.
Is there anyway for plugins to interact with shaders?
Plugins can't currently get the shader pixels. But that's just because I haven't added them to the plugin protocol yet. But interestingly shaders actually have access to the terminal contents in the form of a pixelated version of the text. And the mouse and cursor position too. So maybe there's something you could do purely in a shader.
Tbh I think giving the user voice as to whether to play them would be a better experience anyway, but it's really unusable as is.
Regardless of the fullscreen aspect, and understanding you wanted something jiff-like, I also don’t care much for auto playing video. It doesn’t matter too much if it’s small (as this is intended), silent (as terminals typically are), and doesn’t hoist control of my browser.
Edit: forgot to say that this looks really cool, great work!
Editedit: also forgot to mention that the thumbnails are super blurry on my phone, and after the one video took control of the screen, all the other thumbnails went black.
Thanks to another commenter I've added `playsinline` to the video tag, so hopefully that fixes it.
What do you think a suitable size for all these video/gif assets is? I'd be totally happy to move to .gif or animated .webp but I can seem to get they're filesizes down to a reasonable size.
https://www.reddit.com/r/unixporn/ https://github.com/fosslife/awesome-ricing
https://en.wikipedia.org/wiki/Rice_burner
As Wikipedia relates, "rice burning" refers to a technique of clearing the roots of a rice paddy with fire after a harvest, a bit like slash-and-burn in forestry, and "rice burner" was indeed used as a slur against East Asian people in the second quarter of the twentieth century.
However, simlevesque is not wrong—the term is not usually used in the modding community in a bigoted manner, despite its obvious past association with bigotry. Rather, because Japanese cars were affordable, modding them was seen as cheap, so a car enthusiast with a modded Japanese car was considered a wannabe or imposter, especially if the modifications made their car superficially resemble traits associated with expensive American and European muscle cars, such as extra tailpipes or a louder engine. The ultimate vehicle for these modding jobs was the Honda Civic, which was plentiful and had lots of kits made for it; when Honda released the high-performance Type R edition street racers were quick to expand the "R" to "Rice" (only a mild alteration of the intended meaning, which was something like "Racetrack-worthy.")
In computing, the jargon of "ricing" or "being a ricer" carries a slight air of self-deprecation because front-end customization enthusiasts recognize their endeavors are shallow—many of them can barely administrate the Arch Linux installs they've set up, and almost none of them actually do any programming. The heart of this community remains 4chan's /g/ board, though arguably Reddit owes its entire existence to such people.
That’s already a solved problem. You use a terminal theme that produces high contrast against all the 16 terminal colours.
Plenty of good themes exist.
The bigger problem, in my opinion, is software that uses 8 bit or 16 bit colour ANSI codes and thus overrides your terminals theme. Personally I consider this rude behaviour but I know there is a subset of HN that disagrees with me here.
This is why we can’t have nice things.
I think the fact is that small palettes come from the days of lower resources, not from efficient program design.