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.

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

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.

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.

    <video autoplay loop muted playsinline>

    <video autoplay loop muted>

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.

But if you're asking is this a term in common usage in software, then yes, it is.