Show HN: Term.everything – Run any GUI app in the terminal
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 technical, so please ask if you have any questions.[How I Did It](<https://github.com/mmulet/term.everything/blob/main/resource...>)*technically only Wayland apps and x11 apps with Xwayland. But on Linux that’s mostly everything.
622 points by mmulet - 101 comments
Also someone mentioned a cool project like carbonyl. They also mentioned brow.sh which I have heard but they described it in detail so that's another plus when term.everything kind of projects come they drag other cool projects to he foreground
Point 1 of mine may be pure superstition.
How term.everything works on tty I don't know maybe it will be horriblebecause of the resolution thing but still it's a nice direction.
I am sure it was a great and fun learning experience.
Well done !
EDIT: nevermind, doing this with Docker seems much easier than I expected [0]. I'll try it tomorrow, I'm curious to see if the proposed solution works on Windows as well.
[0] https://medium.com/@priyamsanodiya340/running-gui-applicatio...
[1] https://www.brow.sh/
Sure am glad of the broadband Internet and modern "powerhouse" PCs we have so readily available today. Hell, even the computer most everyone carries in their pocket these days is infinitely more powerful than the average desktop machines of my childhood. :)
Thanks for the reminder
But I remember the BB demo and I still remember these catchy s3m modules...
https://aa-project.sourceforge.net/bb/
And, well, not AA, but I still play today tons of text adventures and roguelikes (and BSDgames and such), and my main X environment it's CLI/TUI based except for CWM (Window manager), MPV/MuPDF/NSxiv (images) and djview4 for DJVU files..
your animal brain hardwired to discern the direction of gaze of the eyes facing you (citations appreciated)...
Helps me find the mouse cursor on a big screen if I lose track, even with small parallax angle.
On macOS, I just wiggle the mouse back and forth, and the cursor gets really big, it pops out at you.
I generally don't keep `xeyes` running. But it's a righteous, venerable hack.
I run a ttyd server to get terminal over https, and I have used carbonyl over that to get work done. That's limited to a web browser (to get access to resources not exposed via the public internet), so having full GUI support is very useful
But can it run doom?
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 it! Not ideal, but it does work, and it it playable.
I used to write telnet games so I know all about keypress up never coming through. Even with immediate mode (so repeated keys will send repeated key codes while held down) it never tells you when it stops. You have to read the buffer ascii byte by byte. Still, awesome to see. Great work!!!
http://zemljanka.sourceforge.net/cursed/screenshots/
This is pretty much that but supercharged. Definitely really cool to see. Good work!
The protocol is sort of:
1. I'd like you to display this PNG. Here's the data: ...
2. Ok I've got the data.
3. Ok now display it at this position.
4. Ok now remove it from the screen.
We're talking motion-PNG here. Just think about how awful that is.
I wish someone would add some kind of AV1-over-terminal protocol. That would be actually useful.
The other thing I was going to try was a custom GUI that used normal terminal text for the text of widgets, but Kitty images for the rest. It's quite a hard problem though.
It isn't: and even copy paste is hard. Clever people write apps that are bash_completion friendly.
If first main arg is bash friendly
mycli myfunc ...
Myour whole cliapp becomes "discoverable" with one tab keystroke that you probably already typed hopefully anyway.
Never need to advertise a new feature.
Deprecate by removing from completion without breaking scripts.
Then _everything_ already is in your cli, because someone already did it.
Another similar thing that I'd been meaning to look into is the RDP remote apps stuff.
That means you win the secret prize! A custom Gwerm T-shirt! I’ll send the details to the Gmail you have linked to your account.
I would go for weeks just in a large framebuffer terminal, no GUI running. And I still run some servers that way.
Terminally insanely great!
https://github.com/fathyb/carbonyl
P.S. This is very cool btw.
https://github.com/chase/awrit
Hopefully supports iPadOS one day.
Absolutely no mouse support though, anyone know of an iPad ssh client with mouse support?
(still working on getting vscode to run smoothly)
Blink terminal for iOS and iPadOS. Ships with vscode support built in too.
- doesTerm.everything run inside tmux with automatic window resizing? I guess not, but it would be cool
2. I think it will work, but I haven't tried. I redraw the terminal window every time the "termed" window updates. So, if you are playing a video for example and you dynamically resize the window, it should update the size automatically. If you are viewing a static window it might not.
A note to myself: this won't work in the text mode.
https://news.ycombinator.com/item?id=45203700
Nicely done!
I love it.
https://github.com/enfp-dev-studio/node-mac-virtual-display/...
https://github.com/wayland-transpositor/wprs
Thanks for sharing!
The reason the terminal ecosystem doesn't get much more sophisticated over time isn't just the herd-of-cats fragmentation, but also evaporative cooling: people who do really cool things with terminal come to realize that what they really want is remote desktop (perhaps rootless) and leave terminal stuff as-is while they invest in more sophisticated systems instead.
1: https://github.com/Julien-cpsn/desktop-tui
1. https://gitlab.freedesktop.org/mstoeckl/waypipe
It already does that[1].
> But there is already waypipe¹ to do that kind of remoting.
That requires Wayland on the client side, doesn't it? I don't expect this to be super-practical anyway, but it's fun to see how far you can push a terminal.
[1] "If your terminal supports images (like kitty or iterm2) you can render windows at full resolution (performance may degrade)."