term.everything

I use chafa in term.everything[0], and I have nothing but good things to say about it! hpjansson is a great maintainer too, if anything even seems like it's wrong with chafa he will chime in with a fix or a suggestion[1] (I'm not the only one he does this with too [2][3]). I would definitely recommend this lib for anyone doing terminal graphics. [0]https://github.com/mmulet/term.everything [1]https://github.com/mmulet/term.everything/issues/5 [2]https://lobste.rs/s/qh6lil/chafa_terminal_graphics_for_21st_... [3]https://github.com/wong-justin/vic/issues/1#issue-2586904982

I use alpine for this [1] reason, but I will admit that this is a premature-optimization. I haven’t actually ran into the problem myself. —— Your code is great, I do basically the same thing (great minds think alike!). The only thing I want to add is that cgo supports pkg-config directly [2] via // #cgo pkg-config: $lib So you don’t have to pass in linker flags manually. It’s incredibly convenient. [1]https://stackoverflow.com/questions/57476533/why-is-statical... [2]https://github.com/mmulet/term.everything/blob/def8c93a3db25...

List of troubles: [1]https://github.com/mmulet/term.everything/issues/28 [2]https://github.com/mmulet/term.everything/issues/18 (although this issue later gets sidetracked to a build issue) [3]https://github.com/mmulet/term.everything/issues/14 [4]https://github.com/mmulet/term.everything/issues/7

I didn't see an explanation in the README that part of what the first GIF[1] shows is an effect created by video editing software (and not a screencapture that's just demonstrating the program actually running). "Screen images simulated" are the words usually chosen to start off the disclaimers in fine print shown at the bottom of the screen when similar effects appear in commercials. I think that it would make sense to adopt a similar explanation wrt the effect used for the GIF. 1. <https://github.com/mmulet/term.everything/blob/main/resource...>

I ran into this issue when porting term.everything[0] from typescript to go. I had some c library dependencies that I did need to link, so I had to use cgo. My solution was to do the build process on alpine linux[1] and use static linking[2]. This way it statically links musl libc, which is much friendlier with static linking than glibc. Now, I have a static binary that runs in alpine, Debian, and even bare containers. Since I have made the change, I have not had anyone open any issues saying they had problems running it on their machines. (Unlike when I was using AppImages, which caused much more trouble than I expected) [0] https://github.com/mmulet/term.everything look at distribute.sh and the makefile to see how I did it. [1]in a podman or docker container [2] -ldflags '-extldflags "-static"'

There is an in-terminal wayland compositor (or two?) out there, fwiw. Edit- one example https://github.com/mmulet/term.everything

A few years back, I was deploying, operating and debugging a Hadoop cluster with Kerberos enabled behind a firewall with only the SSH port being opened. Without a web browser would have been a much more complicated task. I ended up installing the X11 client on my local macOS and the all Gnome + Firefox on one of the cluster's node. Something that is not doable with Wayland. This project work like a charm, here is a quick example on how to test it inside an Incus container (I had to install 2 additional dependencies). # Work with Gnome terminal but resolution is much better in something supporting images apt install -y kitty kitty # Create an incus container incus --project default launch images:ubuntu/24.04 term incus --project default shell term # Install dependencies apt install -y curl firefox libharfbuzz0b libfontconfi

Ask and ye shall receive: Running doom: https://github.com/mmulet/term.everything/blob/main/resource... I had the change a couple of line to make it work because term.everything takes input only from stdin (this way it works of ssh and is pretty broadly compatible across terminals). 1. I had to remap another key to the control key (which is usually used to send signals like sigterm) 2. Then I had to change the timeout in which keys are pressed. When using stdin, you get a keydown event, but you don't get a key up event (ever). So I have to guess when you want to key up. Most of the time, I can send key up right away. But, it looks like doom has some sort of key debounce, so I had to wait 50-100 ms for keyup. Then there is the problem of if you want to walk forward in games you usually hold down up arrow, but now you have to rapidly press

Behold! running on the iPad! Screen Recording - https://github.com/mmulet/term.everything/blob/main/resource... A video of it on the iPad - https://github.com/mmulet/term.everything/blob/main/resource... Absolutely no mouse support though, anyone know of an iPad ssh client with mouse support? (still working on getting vscode to run smoothly)

I made a built-from scratch Wayland Compositor to display any GUI app* in the terminal! I think there is a lot of unexplored potential in custom Wayland compositors, a lot of really cool things you can embed existing applications into! So, I started with embedding apps into the terminal because that is the easiest input/output (output is just utf-8 and I use the great `chafa` library for that, and I just read from stdin for the input). If you have any other ideas for cool Wayland compositors, let me know. I purposedly wrote 80% the app in Typescript to appeal to the most developers and attract cool contributions (I do all drawing with the familiar Canvas2D api, so if there is interest, I can also fork this out into a cool Terminal canvas, let me know!) I have a blog post here about how I did it, but it’s pretty high level and non technica