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.
> 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.
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 12 hours ago [-]
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 11 hours ago [-]
It’s very widely supported from my experience. This is how asciinema captures terminal palette.
tombh 15 hours ago [-]
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.
djaychela 15 hours ago [-]
Id probably have an easier time finding out about this project if it didn't full screen auto play videos as I scroll?
tombh 15 hours ago [-]
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 14 hours ago [-]
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 12 hours ago [-]
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.
eieio 7 hours ago [-]
I think you just need to add "playsinline" to your videos so that they play inline on mobile devices instead of fullscreening.
<video autoplay loop muted playsinline>
instead of your current
<video autoplay loop muted>
cool project :)
ramon156 18 hours ago [-]
This is like the pinnacle of term ricing, I love it
phatskat 12 hours ago [-]
Ricing?
efilife 12 hours ago [-]
Ricing means making your setup pretty with extensive customization.
A 'ricer' is a small Japanese sports car (e.g. Subaru WRX or Mitsubishi Evo) souped up or given fancy paint job and spoilers etc). Rice for the country of origin.
rhet0rica 3 hours ago [-]
To further elucidate, it's a contraction of "rice burner," suggesting the vehicle uses rice as fuel.
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.
notnmeyer 9 hours ago [-]
Pretty sure it’s racist (or at least pejorative) in origin referring to the asian car customization / import scene.
simlevesque 6 hours ago [-]
It's the term used by the community.
hnlmorg 12 hours ago [-]
> 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 11 hours ago [-]
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)
So, it is supported or not? Looks great by the way.
tombh 17 hours ago [-]
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.
PeterStuer 3 hours ago [-]
On which hypervisor?
em-bee 17 hours ago [-]
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 16 hours ago [-]
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 14 hours ago [-]
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 14 hours ago [-]
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.
nerflad 19 hours ago [-]
This is brilliant, thanks for making public and best wishes
d4rkp4ttern 11 hours ago [-]
Lost me at “compositor” - are (tech) people supposed to know what that is?
ctxc 36 minutes ago [-]
Well I didn't either, so join the boat I guess :)
azornathogron 10 hours ago [-]
Not sure what you mean by "supposed to know". There's no universal "tech syllabus", so there's nothing (or everything?) that you're supposed to know.
But if you're asking is this a term in common usage in software, then yes, it is.
otterpro 17 hours ago [-]
I'd probably run cmatrix for looks or maybe htop on the background. Also, Rick-rolled in the screenshot.
msgodel 17 hours ago [-]
It seems like what you really wanted was a streaming SVG renderer and not a VTE.
I kind of like that idea.
tombh 17 hours ago [-]
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 17 hours ago [-]
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 17 hours ago [-]
I'm curious about your minimal UI API idea.
grandma_tea 18 hours ago [-]
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 18 hours ago [-]
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.
pacifika 19 hours ago [-]
Nice idea, I like the out of the box thinking on display.
gfalcao 15 hours ago [-]
SUPER COOL
MatthewPhillips 17 hours ago [-]
This looks amazing. Well done.
cenobyte 14 hours ago [-]
Because why shouldn't my terminal be the largest consumer of memory on my PC?
tines 14 hours ago [-]
I paid for 32GB, I’m gonna use 32GB.
ainiriand 17 hours ago [-]
Can it run doom?
tombh 17 hours ago [-]
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.
apwell23 13 hours ago [-]
unfortunately sounds like Tatti ( google/llm this OP )
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...
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.
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.
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.
But if you're asking is this a term in common usage in software, then yes, it is.
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.