Well, not 100% useless: I can see its use for applications running inside Docker containers. Yes, there are ways to have GUI applications rendered from the inside of a container, but maybe this is easier than getting the Dockerfile right.
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.
Yeah, I can’t explain why this project makes me so happy because I struggle to think of any time where I’d need this, but it puts a big, dumb grin on my face.
Well, you can run apps on any less capable device with ssh and proper terminal display. You can limit data usage by offloading video buffering to the host (however not sure if that's net positive saving). And put the host behind VPN to avoid getting region blocks.
It reminds me a bit of chindōgu, the Japanese art (?) of useless inventions. There's a particular delight to ingenious, but absurd or useless creations.
Emacs it's full of chindogus. Also, there's geekcode, xroach, megahal/hailo, xneko, aatv and mplayer rendering videos over aalib, aaquake, eforth running in the subleq virtual machine...
I started working on this with the Kitty image protocol, but unfortunately that protocol is really unsuited to this sort of thing. Performance will be awful.
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.
This is one of those things that pushes the boundaries to nowhere, yet everywhere at the same time whilst being incredibly awesome and something you can show off ad infinitum. Outstanding! Not sure how we’ll implement vdi now! Gives ghost in the shell a whole new meaning.
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.
This is interesting, but there was something that was even more impressive many years ago: a GTK theme that rendered all decoration and widgets using text chars and a GDK backend that rendered to text. Combine both and you could run any GTK app on a terminal with legible text and a beautiful TUI.
This is such a cool project. Personally, I think there are so many interesting use cases that can be built on top of Wayland, like https://github.com/udevbe/greenfield
and this
I remember the carbonyl project to run chromium in the terminal that got me really excited (https://github.com/fathyb/carbonyl) but it eventually became unmaintained.
This is pretty much that but supercharged. Definitely really cool to see. Good work!
This could be used on build machines I own where I occasionally need to interact with the desktop and/or browser on the machine and vnc or other desktop sharing is impractical or exposes security issues.
This is pretty cool, I can see this being useful when I need to run a one-off remotely. Not sure about attaching a running program then detaching again, or mirroring... I wouldn't mind being able to SSH to my desktop and manipulate say the running Discord client, or similar.
Another similar thing that I'd been meaning to look into is the RDP remote apps stuff.
It was an example, not the only use case. 99% of what I want to do remote is just fine over SSH (over Wireguard)... Mostly remote VS Code usage since my desktop is much beefier than my laptop when travelling.
Stupid, love it. Occasionally I'll use shaderglass ascii shader on oled screen to play videos with pixel ratio that makes UI unreadable, but it's charming experience.
1. Yes, but it depends on your compositor because your compositor needs to be able to run as a nested Wayland client. I think there is support for this in wlroots based Wayland compositors, but I'm not sure if hyperland supports it.
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.
Wow. This is amazing. I have started running a lot of stuff in containers by default for a whole host of reasons, and this may make my workflow even better on the occasions when I want to run a graphical app.
It is funny but this is what I wished things did when I first started using Linux back in the day. '98-'99 timeframe, then I "learned" better that there was Xorg/X11,etc.
I truly appreciate the relational thinking and pointing out other projects that might interest ppl who are excited about this :) Having said that, term.everything seems to be much larger in scope than a browser, unless I'm mistaken
Neat! I did a similar project many years ago just to see if I could with ANSI color stuff to animate video in my terminal. Worked really well, but it looked like absolute butt (unlike this project).
No you do not. It works on x11 and Wayland host systems. I built the Wayland compositor from scratch and it does not have any dependencies on libwayland. So, you don’t have to install Wayland at all.
I definitely want to make a macOS version, but I haven’t even looked into it yet. So, I don’t know the level of hacking required. It definitely doesn’t sound like anything Apple would have an api for, so it would probably be a vnc or accessibility api trick.
I think there is an API (that was added with sidecar) to create a virtual display. So at best you could retrieve the framebuffer and then display that. I don't think there is an easy exposed way to get per-window information, aside from doing a screencapture (which likely would not work if you also wanted to hide the window).
Interesting… do you have a link to the docs? The easiest thing prob would be to set the window to be fullscreen, but on that virtual display. That would accomplish per window screen capture.
Great job! If you tug on this thread long and hard enough, you develop this enough and you get RDP (which you can try via xrdp, GNOME's remoting thing, etc.).
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.
"I feel like every single day I hear about another terminal file viewer. I say, stop making terminal file viewers because you can just use the file viewer you already have! In your terminal!"
LMAO
You could use a terminal graphics protocol to render real graphics. But there is already waypipe¹ to do that kind of remoting. Without using an actual terminal.
> You could use a terminal graphics protocol to render real graphics.
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)."
That's awesomely useless, it straddles the line between programming and art.
I am sure it was a great and fun learning experience.
Well done !
Well, not 100% useless: I can see its use for applications running inside Docker containers. Yes, there are ways to have GUI applications rendered from the inside of a container, but maybe this is easier than getting the Dockerfile right.
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...
Yeah, I can’t explain why this project makes me so happy because I struggle to think of any time where I’d need this, but it puts a big, dumb grin on my face.
Well, you can run apps on any less capable device with ssh and proper terminal display. You can limit data usage by offloading video buffering to the host (however not sure if that's net positive saving). And put the host behind VPN to avoid getting region blocks.
Oops, we've invented X
It reminds me a bit of chindōgu, the Japanese art (?) of useless inventions. There's a particular delight to ingenious, but absurd or useless creations.
That’s a term I’ve not heard in literally decades.
Thanks for the reminder
Emacs it's full of chindogus. Also, there's geekcode, xroach, megahal/hailo, xneko, aatv and mplayer rendering videos over aalib, aaquake, eforth running in the subleq virtual machine...
I remember watching the World Cup over telnet with one of those aalib libraries years ago. The signal arrived 5 seconds earlier than the TV :)
I’m a fan of `xeyes`
xeyes can be Actually Useful; two eyes always looking at the cursor...
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.
<3
I came here to make the same comment. I want to try this myself just for the fun of it and the grin it will put on my face. Nice work!
You can have a <3 too!
I started working on this with the Kitty image protocol, but unfortunately that protocol is really unsuited to this sort of thing. Performance will be awful.
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.
https://www.youtube.com/watch?v=dcjkezf1ARY
This is one of those things that pushes the boundaries to nowhere, yet everywhere at the same time whilst being incredibly awesome and something you can show off ad infinitum. Outstanding! Not sure how we’ll implement vdi now! Gives ghost in the shell a whole new meaning.
But can it run doom?
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 it! Not ideal, but it does work, and it it playable.
aaquake ran under ASCII terminals before this ever existed.
This is interesting, but there was something that was even more impressive many years ago: a GTK theme that rendered all decoration and widgets using text chars and a GDK backend that rendered to text. Combine both and you could run any GTK app on a terminal with legible text and a beautiful TUI.
http://zemljanka.sourceforge.net/cursed/screenshots/
Link is dead. Archive: https://web.archive.org/web/20080924152845/http://zemljanka....
why did this go away?
This is such a cool project. Personally, I think there are so many interesting use cases that can be built on top of Wayland, like https://github.com/udevbe/greenfield and this
I remember the carbonyl project to run chromium in the terminal that got me really excited (https://github.com/fathyb/carbonyl) but it eventually became unmaintained.
This is pretty much that but supercharged. Definitely really cool to see. Good work!
Another custom wayland compositor, this one not written in a scripting language.
https://github.com/wayland-transpositor/wprs
I love this.
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!
This could be used on build machines I own where I occasionally need to interact with the desktop and/or browser on the machine and vnc or other desktop sharing is impractical or exposes security issues.
Someone needs to make bash_completion really trivial to write.
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.
This is pretty cool, I can see this being useful when I need to run a one-off remotely. Not sure about attaching a running program then detaching again, or mirroring... I wouldn't mind being able to SSH to my desktop and manipulate say the running Discord client, or similar.
Another similar thing that I'd been meaning to look into is the RDP remote apps stuff.
Just use a CLI discord client, or fire up an IRC client against some Bitlbee server.
It was an example, not the only use case. 99% of what I want to do remote is just fine over SSH (over Wireguard)... Mostly remote VS Code usage since my desktop is much beefier than my laptop when travelling.
I wish you success in further development, don't stop!
Thanks!
Wow. I love this! I actually have a specific, esoteric use for this: VSCode on iPad
Hopefully supports iPadOS one day.
I tend to use https://github.com/coder/code-server#code-server for my remote development needs.
I know there are ssh clients for iPad. So it should work. I’m going to try it right now!
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)
> anyone know of an iPad ssh client with mouse support
Blink terminal for iOS and iPadOS. Ships with vscode support built in too.
> in the terminal
A note to myself: this won't work in the text mode.
Isn't the first example (with the cartoon) in text mode?
Super cool! I also really am glad you added videos and examples in your github repo its nice to get an overview
Stupid, love it. Occasionally I'll use shaderglass ascii shader on oled screen to play videos with pixel ratio that makes UI unreadable, but it's charming experience.
- Can you run a compositor inside a compositor? I'd love to just ssh to a server and run hyprland
- doesTerm.everything run inside tmux with automatic window resizing? I guess not, but it would be cool
1. Yes, but it depends on your compositor because your compositor needs to be able to run as a nested Wayland client. I think there is support for this in wlroots based Wayland compositors, but I'm not sure if hyperland supports it.
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.
Wow. This is amazing. I have started running a lot of stuff in containers by default for a whole host of reasons, and this may make my workflow even better on the occasions when I want to run a graphical app.
It is funny but this is what I wished things did when I first started using Linux back in the day. '98-'99 timeframe, then I "learned" better that there was Xorg/X11,etc.
I remember seeing something similar named Carbonyl a while back. What a coincidence lol.
https://github.com/fathyb/carbonyl
P.S. This is very cool btw.
I truly appreciate the relational thinking and pointing out other projects that might interest ppl who are excited about this :) Having said that, term.everything seems to be much larger in scope than a browser, unless I'm mistaken
That’s right. These other projects are awesome, but they’re attempting something different. It’s apples to oranges.
Awrit is also similar.
https://github.com/chase/awrit
Neat! I did a similar project many years ago just to see if I could with ANSI color stuff to animate video in my terminal. Worked really well, but it looked like absolute butt (unlike this project).
Nicely done!
Can it run Doom?
Doom time!
https://news.ycombinator.com/item?id=45203700
It can. GIFs forthcoming.
Looks like archive.org is down right now… so I guess we’ll have to wait for GIFS. Sorry:
This is one of those things I'm going to keep in my back pocket for a very specific time I need it for a weird reason.
I love it.
Do I need to be using wayland to try this? I'm still on x11.
No you do not. It works on x11 and Wayland host systems. I built the Wayland compositor from scratch and it does not have any dependencies on libwayland. So, you don’t have to install Wayland at all.
This is so cool, thanks for sharing! Having this on a Mac would be great but I understand that this might be a huge undertaking :)
I definitely want to make a macOS version, but I haven’t even looked into it yet. So, I don’t know the level of hacking required. It definitely doesn’t sound like anything Apple would have an api for, so it would probably be a vnc or accessibility api trick.
I think there is an API (that was added with sidecar) to create a virtual display. So at best you could retrieve the framebuffer and then display that. I don't think there is an easy exposed way to get per-window information, aside from doing a screencapture (which likely would not work if you also wanted to hide the window).
Interesting… do you have a link to the docs? The easiest thing prob would be to set the window to be fullscreen, but on that virtual display. That would accomplish per window screen capture.
It's a private API CGVirtualDisplay, but mostly well reverse engineered. Here's one example I found of a wrapper library
https://github.com/enfp-dev-studio/node-mac-virtual-display/...
100. Thanks!
I was about to asked about X11, but ended up learning about Wayland.
Thanks for sharing!
This is absolutely unhinged and I love everything about it
This will be very useful when it exits beta.
insane ! but i still wonder for the use case ^^
Outstanding project! Keep it up. If it ever gets renamed, consider - Terminal.All, T.All, or TAll.
Termin-all was right there
The deciding factor was that I just liked using term as a verb.
This is an incredibly cool project and you should be proud for building it.
Wow this is incredible
Great job! If you tug on this thread long and hard enough, you develop this enough and you get RDP (which you can try via xrdp, GNOME's remoting thing, etc.).
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.
"I feel like every single day I hear about another terminal file viewer. I say, stop making terminal file viewers because you can just use the file viewer you already have! In your terminal!" LMAO
Combine this with desktop-tui[1] and say goodbye to graphical desktop managers forever!
1: https://github.com/Julien-cpsn/desktop-tui
Love it :)
<3
Love it!
<3
You could use a terminal graphics protocol to render real graphics. But there is already waypipe¹ to do that kind of remoting. Without using an actual terminal.
1. https://gitlab.freedesktop.org/mstoeckl/waypipe
> You could use a terminal graphics protocol to render real graphics.
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)."