aboutsummaryrefslogtreecommitdiffstats
path: root/src/input.c
diff options
context:
space:
mode:
authoruser <user@clank>2026-08-16 01:06:42 +0200
committeruser <user@clank>2026-08-16 01:06:42 +0200
commit3b9c1d987db7dae1db68a8ea304e8227344a1cdb (patch)
treeb2aa66a61e2111720115442611ca092d261c161c /src/input.c
parentsl0ppty: a reply is never a request (diff)
downloadslosh-3b9c1d987db7dae1db68a8ea304e8227344a1cdb.tar.gz
slosh-3b9c1d987db7dae1db68a8ea304e8227344a1cdb.tar.xz
slosh-3b9c1d987db7dae1db68a8ea304e8227344a1cdb.zip
sl0ppty: a pane can set its own shaders
printf '\033]5577;1;shader;chrome;tint color="#ff5fd7" amount="abs(t / 8 % 510 - 255)"\033\\' The field after `shader` is which rect -- `content` or `chrome` -- and the rest of the payload is a chain in exactly the syntax a `shaders { }` block uses, taken verbatim so that `;` can go on separating entries. Empty text clears that chain. The session answers on the program's stdin, `shader-reply;ok` or `shader-reply;error;bad amount for tint: ...`, because a prototyping loop that gets no answer cannot tell a typo from a build without the feature. `contrib/shader-repl` is the prompt this exists for: type a chain, watch the pane, and `:paste` prints what you have as a config block. Both ends are the same parser, so what you arrive at is what you can keep -- verified by pasting `:paste`'s output into a file, linting it, and checking the frame comes out the same colour. **D13 said this was impossible on purpose, and the reasoning stands**: a program that can restyle the session it happens to be running in is a hazard, and `cat hostile.txt` should not dim your panes. But *impossible* was the wrong shape for it -- editing a file, saving, looking and guessing again is slow enough that shaders go unwritten. So it takes `in_band_shaders true`, one line of consent, and it is scoped to the pane that asked: its own two chains, never its neighbour's, never what the config said about anyone else. There is a test for the neighbour. Each chain owns the programs its expressions compiled to, and is swapped in whole, so a chain that turns out not to read leaves the pane looking like it did rather than half-restyled. Measured: 1,800 replacements of an animated chain, resident size flat after the first pass. Also here, because it is the same paint order: the chrome chain now sits between the config's and policy's, exactly where the content chain does. Dead code out -- `app_shade_add`/`app_shade_clear`/`app_shade_count` had no callers and their comment claimed the opposite of what this commit does.
Diffstat (limited to 'src/input.c')
0 files changed, 0 insertions, 0 deletions