Show HN: Tattoy – a text-based terminal compositor

This looks really cool, I'd like to give it a go. The idea of taking a screenshot of the terminal and then parsing that to determine the true colour support is definitely novel, though perhaps so, because for me I can't get it to work. Are there any debug flags I can enable?

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

I see you added then removed Windows from your Release plan:

https://github.com/tattoy-org/tattoy/issues/42

So, it is supported or not? Looks great by the way.

Repo link https://github.com/tattoy-org/tattoy

Tattoy manages its own scrollback buffer (like say `tmux` does), and so can therefore also provide its own scrollbar.

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?

I especially like the idea of evolving the protocol. Just because the text first ui is a great idea doesn’t mean we achieved perfection with ansi escape codes.

This is brilliant, thanks for making public and best wishes

I'd probably run cmatrix for looks or maybe htop on the background. Also, Rick-rolled in the screenshot.

do you virtualise the terminal state fully or just overlay visual layers? like if a child process writes malformed escape sequences or resizes mid frame, who owns the state resolution : tattoy or the underlying tty?

It seems like what you really wanted was a streaming SVG renderer and not a VTE.

I kind of like that idea.

Because why shouldn't my terminal be the largest consumer of memory on my PC?

Interesting project. You might check out Arcan (https://arcan-fe.com/) if you've never heard of it. (EDIT: I see author recently added a link: https://github.com/tattoy-org/tattoy/blob/main/website/conte... )

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.)

Oh wow, now I can finally have terminal that creates fire effects the faster I type! (if I ever get the time to make the plugin)

Is there anyway for plugins to interact with shaders?

Nice idea, I like the out of the box thinking on display.

This looks amazing. Well done.

Can it run doom?

Thank you for (1) sharing a fascinating project that has nothing to do with "AI," (2) mentioning not once, anywhere, even in the repo docs (as far as I can tell) that Tattoy is written in Rust, and (3) not writing docs that look and sound like ad copy intended to woo VCs or outcompete other software packages.

Seriously, this is high-quality work (as far as I can tell -- though it is way outside of my area of expertise) and the presentation is a model of class and taste. This is what I come to HN for, and it's a badly needed shot of motivation to start, finally, working on my own terminal-related project.

SUPER COOL

Id probably have an easier time finding out about this project if it didn't full screen auto play videos as I scroll?

This is like the pinnacle of term ricing, I love it

> 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.

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.

Now we get Rickrolled in the terminal. Great! /s.