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...
WSL had non-accelerated wayland support at one point in time.
Was it before "most distros"?
I don't understand what you think that amounts to.
Wayland support in Linux-land typically means that the software supports running in your wayland compositor.
Windows famously is not a wayland compositor, no matter how much you try to bend reality.
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.
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. :)
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!!!
# 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 libfontconfig1
curl -L -o term https://github.com/mmulet/term.everything/releases/download/0.5.1/term.everything.mmulet.com-dont_forget_to_chmod_+x_this_file
mv term.everything.mmulet.com-dont_forget_to_chmod_+x_this_file term
chmod u+x term
echo '<h1>Hello</h1>' > test.html
# Start firefox, wait for a few seconds
./term firefox test.htmlThis is pretty much that but supercharged. Definitely really cool to see. Good work!
For example...
$ Xvfb :7 &
[1] 21688
$ xeyes -display :7 &
[2] 21697
$ xwd -display :7 -name xeyes -out /dev/stdout | convert xwd:- sixel:-
Obviously no input though, you would have to use xdotool! The main benefit is that you probably already have all these tools installed :)
https://github.com/fathyb/carbonyl
P.S. This is very cool btw.
Modern UI applications are way too tightly coupled for my liking, and difficult to test especially if you don't practice "separation of concerns", e.g. decoupling the app logic from its presentation.
Haven't looked at the full thing but something like this might allow you to write tests for UI apps without actually having the UI backend...
Another similar thing that I'd been meaning to look into is the RDP remote apps stuff.
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.
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.
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.
But I don't want that anyway. I want something graphical that's actually integrated into the terminal.
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.
- 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.
Nicely done!
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/enfp-dev-studio/node-mac-virtual-display/...
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.
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.
Thanks for sharing!
Also, I'm lost for words, this is plain awesome.
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)."
