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 kind of like that idea.