[HN Gopher] Show HN: Tattoy - a text-based terminal compositor
___________________________________________________________________
Show HN: Tattoy - a text-based terminal compositor
Whereas this is mostly a terminal eye-candy project to get you
street cred, it does have some serious aspects. 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.
Author : tombh
Score : 142 points
Date : 2025-06-13 14:04 UTC (8 hours ago)
(HTM) web link (tattoy.sh)
(TXT) w3m dump (tattoy.sh)
| pvg wrote:
| Repo link https://github.com/tattoy-org/tattoy
| pacifika wrote:
| Nice idea, I like the out of the box thinking on display.
| nerflad wrote:
| This is brilliant, thanks for making public and best wishes
| grandma_tea wrote:
| 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?
| tombh wrote:
| Intenser flames the more you type, great idea!
|
| 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.
| ramon156 wrote:
| This is like the pinnacle of term ricing, I love it
| phatskat wrote:
| Ricing?
| efilife wrote:
| Ricing means making your setup pretty with extensive
| customization.
|
| https://www.reddit.com/r/unixporn/
| https://github.com/fosslife/awesome-ricing
| phatskat wrote:
| Ah I see, but why that term?
| TheSilva wrote:
| 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.
| tombh wrote:
| Thank you.
|
| 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.
| ainiriand wrote:
| Can it run doom?
| tombh wrote:
| There is actually a Shadertoy for Doom!
| https://www.shadertoy.com/view/lldGDr So in theory Tattoy could
| run it, the only thing is that it doesn't currently support
| extra buffers and that Doom shader needs 5 of them.
| msgodel wrote:
| It seems like what you really wanted was a streaming SVG renderer
| and not a VTE.
|
| I kind of like that idea.
| tombh wrote:
| How do you mean? I'm actually not a fan of terminal image
| protocols like Sixel and Kitty's image protocol. I value the
| constraints of only being able to use text. I feel that in some
| ways when we venture into real graphics the soul of the
| terminal is lost.
| msgodel wrote:
| Maybe I'm confused, I guess this is more an aesthetic thing
| than a practical thing. I just see VTEs as a minimal UI API
| for software.
| tombh wrote:
| I'm curious about your minimal UI API idea.
| otterpro wrote:
| I'd probably run cmatrix for looks or maybe htop on the
| background. Also, Rick-rolled in the screenshot.
| em-bee wrote:
| _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?
| tombh wrote:
| Yes, every GUI terminal manages its own scrollback buffer. The
| reason that Tattoy and tmux have their own buffers is because
| they are essentially terminal emulators themselves. For
| instance a terminal emulator may have 10 tmux panes and it
| should of course be possible to view the history of each one.
| Tattoy manages its own scrollback because that's the only way
| to make the scrollback available programatically to other
| processes, like the minimap for example.
|
| 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.
| em-bee wrote:
| my first attempt at using a light theme with gnome-terminal
| gets me white on white either in the prompt or on the
| commandline itself. don't have time to debug that now 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.
| tombh wrote:
| Oh white on white isn't good, sorry about that, I'll look
| into it.
|
| I also have some ideas to make Tattoy into a multiplexer. I
| really like the idea of desaturating and fading unfocussed
| panes.
| MatthewPhillips wrote:
| This looks amazing. Well done.
| tfsh wrote:
| 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
| shiomiru wrote:
| > The idea of taking a screenshot of the terminal and then
| parsing that to determine the true colour support is definitely
| novel,
|
| 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...
| tombh wrote:
| OMG really!? That link is blocked for me for some reason. If
| that OSC code is widely supported it's going to make things
| sooooo much easier.
| hnlmorg wrote:
| It's supported by any xterm compatible terminal emulator.
| But like with most things in this domain, expect plenty of
| edge cases where it _should_ work but doesn't.
| ku1ik wrote:
| It's very widely supported from my experience. This is how
| asciinema captures terminal palette.
| tombh wrote:
| Thanks for trying it out. It looks like either your terminal or
| screenshotter isn't faithfully rendering the pure red marker
| column (it's needed for calibration in the parser). The red
| should be #ff0000, but the screenshot is using #ea3323. I've
| made a Github issue to keep track https://github.com/tattoy-
| org/tattoy/issues/98 If you can add more details it'd really
| useful, I'm sure there'll be more people like you.
| gfalcao wrote:
| SUPER COOL
| djaychela wrote:
| Id probably have an easier time finding out about this project if
| it didn't full screen auto play videos as I scroll?
| tombh wrote:
| I didn't intend for the videos to be fullscreen. They need to
| be small in order to save bandwidth. They're certainly
| autoplaying (to replicate GIF behaviour), but maybe there's a
| bug with them going full screen. What browser are you using?
| djaychela wrote:
| Firefox on ios. They are full the screen and auto play as
| soon as I get to whatever part of the page they are on.
|
| 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.
| phatskat wrote:
| I get the same experience on iOS using the OS web view - my
| guess is because iOS (and maybe android?) don't typically
| play videos in "windowed mode" (for lack of a better term)
| outside of eg Google video snippets which seem to do some
| hacky stuff to keep you "in Google" while watching.
|
| 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.
| cenobyte wrote:
| Because why shouldn't my terminal be the largest consumer of
| memory on my PC?
| tines wrote:
| I paid for 32GB, I'm gonna use 32GB.
| apwell23 wrote:
| unfortunately sounds like Tatti ( google/llm this OP )
| hnlmorg wrote:
| > 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.
| ku1ik wrote:
| My understanding is it ensures proper contrast for all cells
| regardless of the type of fg/bg color (palette, 8 bit, 24 bit).
| So if a program uses 24 bit fg color and a bg from palette (or
| a default one) it would still preserve the contrast. (haven't
| tested, just my impression from reading the docs)
| d4rkp4ttern wrote:
| Lost me at "compositor" - are (tech) people supposed to know what
| that is?
___________________________________________________________________
(page generated 2025-06-13 23:00 UTC)