If you squint, Godot has a cross platform hardware accelerated GUI. The editor is itself, in a sense, a Godot app and has builds for VR Headsets, Android, web apps, all the usual platforms. The extension api works pretty good too for Rust, and Rust itself has a fantastic cross platform and WASM story. It might be cursed, but it can get complicated stuff out the door and in anyone's hands fast.
edit: they also recently created libgodot, which flips the model. Your application owns and controls whatever components you want to pull from Godot. Being open source and relatively legible of a code base you could presumably strip out a lot you don't need.
Yeah, the README doesn't have screenshots; but the docs site does - https://godot-pty.github.io/gpty/ - 1 for now, but each release's blog entry gets the main app page + one for any salient features.
I'll add that in; maybe defaulted to folded on the README, a gallery of app screens or snippets. I need to spend some time on the UX, but yeah, screenshots (and possibly some sort of an intro video that explains features) is something I should've also added to the README.
Can you add a "why?" / "why now?" section?
Don't be another project that is a bunch of how that is leaving out to explain why it exists or exemplify what classes of problems it unlocks solutions for (applicability).
It sort of goes over the "why?"/"why now?"; but TLDR; Wanted to use Godot & Rust in personal project(s) (no pressing need for it) I saw Cate & wondered whether I could use this tech. stack to replicate, instead of web tech. So that's where it all started. I know that if you want to live in the terminal, there's tmux and herdr, and I'm not (also can't) compete with them. But I can surface a terminal that then lets TUI folks stay in their preferred apps. The residual why/why now are largely shaped by what I want (feature-wise) to put into the tool.
And the next big feature I want is a personal knowledge management. Maybe it looks like a complex beast; but the core idea driving my features are what I want on a daily basis without switching context as much. Sorry, I know it's not a great answer, bit rambly.
I tried different terminals and multiplexers for agent development: tty7, Warp, Herdr... Now my favorite is tty7. It does exactly what i wanted from a modern terminal, what Warp should have become.
Fyne.io in Go also doesn't want to support a browser, but that is a great way to expand mindshare (similar to implementing a solid data grid in a UI toolkit).
Appreciate the time you took to point this out. Yes, the docs as they are now are LLM written. It might help a bit more if you can point out to a particular section or file that stands out. If not, no worries, I will plan on doing a manual sweep across all .mds for better (clearer) readability.
While I appreciate the creativity around using a game engine for non gaming applications, this does not seem like a particularly good fit.
If most of your problem is 2d window/text stuff, the web browser is probably the best foundation to work with. UI and hud functionality in COTS game engines is light years behind what chromium and friends can do today.
Agree on Chrome being top-dog in this space. Electron would've been the easy (pragmatic?) choice. But the design decision was to use Godot and not create yet-another-Chrome-Electron app. It's certainly not pretty to look at in its current state.
This is something I'm mainly working on it on my free time so figured why not see how far I could push things.
Godot is a pretty monolithic engine and I don't know if you can really compile it down to a reasonable size for non game use cases. The scripting language is pretty slow and I remember coding in C++ was painful even after 4.0. I think you're better off with Raylib, Bevy or plain SDL.
This is just straight up false. You can compile subsets of the engine even in Godot 3. Godot 4 has made this a first class citizen.
C++ coding is just fine. It's not painful. It can be a bit of boilerplate to expose c++ member fields and functions to the rest of the engine but you get some great power out of that. Just use compile your own module right into the engine. Don't use gdnative.
As someone who's codes a lot of c++ in Godot I really am not sure what your talking about here.
SDL isn't even in the same dimension of usability compared to the Godot editor.
Thanks, wasn't familiar with these, I'll look into them though the project direction is unlikely to change to swap Godot out. As of now, the binaries are in the 60-80 MB range; so not tiny - but not something I'd consider massive for what it is.
Usage has been relatively snappy (could be better, I suppose, I need more time). Definitely not sluggish.
A concern is that RAM usage is on the higher side (this is something I'll look at on the next release).
The concepts/reg-ex redirect is how I was imagining the autonomous agent automation. It does need to be fleshed out a bit more, but essentially, it was an easy way to let a process to know what's happening in another process so it could react appropriately. The e2e tests are a good use-case, but not something I've looked into yet (in theory, the framework should hold up for it)
Original intent was just a hobby/side project. As it grew, I thought maybe posting about it would be alright in case people find the idea interesting.
lmao how is this on the front page at the 2 spot? People upvoting based on seeing buzzwords I assume? It's cool that small projects can get recognition here but this is not useful software
I've done a lot of things reusing/modifying the internals of alacritty [1] to put terminals in things. TeX in the terminal [2], a terminal in minecraft [3], Alacritty in Godot [4], and not pictured, alacritty in a swift plugin for macos/ios/ipados all at various levels of completion.
This is such a cursed combination... I really don't understand what you get from Godot that benefits you for building a TTY "multiplexer."
Wildly vibe-coded to the extent that it's more misguided than Doom on a pregnancy test...
Also looking at OP's notes here, there doesn't even seem to be a need for this to exist, "FPS counter" ..? Perhaps, I don't know, fake terminals on a spaceship or something. Yueash...
a note about "Doom on a preganancy test". It wasn't actually running on the pregnancy test. It was displayed on the tests 1 color LCD screen, but everything else was different hardware. It was a test of hacking the display and what it was capable of in cheap disposable device, not the processing power of the electronics in the test.
If you squint, Godot has a cross platform hardware accelerated GUI. The editor is itself, in a sense, a Godot app and has builds for VR Headsets, Android, web apps, all the usual platforms. The extension api works pretty good too for Rust, and Rust itself has a fantastic cross platform and WASM story. It might be cursed, but it can get complicated stuff out the door and in anyone's hands fast.
edit: they also recently created libgodot, which flips the model. Your application owns and controls whatever components you want to pull from Godot. Being open source and relatively legible of a code base you could presumably strip out a lot you don't need.
Just try to remember accessibility concerns.
A project without screenshots - I dont know how they expect us to understand unless we read everything
Yeah, the README doesn't have screenshots; but the docs site does - https://godot-pty.github.io/gpty/ - 1 for now, but each release's blog entry gets the main app page + one for any salient features.
I'll add that in; maybe defaulted to folded on the README, a gallery of app screens or snippets. I need to spend some time on the UX, but yeah, screenshots (and possibly some sort of an intro video that explains features) is something I should've also added to the README.
Can you add a "why?" / "why now?" section? Don't be another project that is a bunch of how that is leaving out to explain why it exists or exemplify what classes of problems it unlocks solutions for (applicability).
I had been thinking about that & wrote a blog post last week: https://godot-pty.github.io/gpty/docs/overview/story/
It sort of goes over the "why?"/"why now?"; but TLDR; Wanted to use Godot & Rust in personal project(s) (no pressing need for it) I saw Cate & wondered whether I could use this tech. stack to replicate, instead of web tech. So that's where it all started. I know that if you want to live in the terminal, there's tmux and herdr, and I'm not (also can't) compete with them. But I can surface a terminal that then lets TUI folks stay in their preferred apps. The residual why/why now are largely shaped by what I want (feature-wise) to put into the tool.
And the next big feature I want is a personal knowledge management. Maybe it looks like a complex beast; but the core idea driving my features are what I want on a daily basis without switching context as much. Sorry, I know it's not a great answer, bit rambly.
Love to see Godot used creatively beyond games! The terminal is for sure an area that can see innovation, why not!
I tried different terminals and multiplexers for agent development: tty7, Warp, Herdr... Now my favorite is tty7. It does exactly what i wanted from a modern terminal, what Warp should have become.
What would you say was the one (or multiple) killer feature(s) that took you away from herdr/warp/tmux/etc. and towards tty7?
Fyne.io in Go also doesn't want to support a browser, but that is a great way to expand mindshare (similar to implementing a solid data grid in a UI toolkit).
The documentation is really hard to read. It's full of claudisms and verbosity. I highly recommend you to do a human review on the whole thing.
Appreciate the time you took to point this out. Yes, the docs as they are now are LLM written. It might help a bit more if you can point out to a particular section or file that stands out. If not, no worries, I will plan on doing a manual sweep across all .mds for better (clearer) readability.
While I appreciate the creativity around using a game engine for non gaming applications, this does not seem like a particularly good fit.
If most of your problem is 2d window/text stuff, the web browser is probably the best foundation to work with. UI and hud functionality in COTS game engines is light years behind what chromium and friends can do today.
Agree on Chrome being top-dog in this space. Electron would've been the easy (pragmatic?) choice. But the design decision was to use Godot and not create yet-another-Chrome-Electron app. It's certainly not pretty to look at in its current state.
This is something I'm mainly working on it on my free time so figured why not see how far I could push things.
Godot is a pretty monolithic engine and I don't know if you can really compile it down to a reasonable size for non game use cases. The scripting language is pretty slow and I remember coding in C++ was painful even after 4.0. I think you're better off with Raylib, Bevy or plain SDL.
This is just straight up false. You can compile subsets of the engine even in Godot 3. Godot 4 has made this a first class citizen.
C++ coding is just fine. It's not painful. It can be a bit of boilerplate to expose c++ member fields and functions to the rest of the engine but you get some great power out of that. Just use compile your own module right into the engine. Don't use gdnative.
As someone who's codes a lot of c++ in Godot I really am not sure what your talking about here.
SDL isn't even in the same dimension of usability compared to the Godot editor.
Thanks, wasn't familiar with these, I'll look into them though the project direction is unlikely to change to swap Godot out. As of now, the binaries are in the 60-80 MB range; so not tiny - but not something I'd consider massive for what it is.
Usage has been relatively snappy (could be better, I suppose, I need more time). Definitely not sluggish.
A concern is that RAM usage is on the higher side (this is something I'll look at on the next release).
Is the intended use to improve automation by agents during verification? To make it easier to drive Godot apps during e2e tests, for example?
The concepts/reg-ex redirect is how I was imagining the autonomous agent automation. It does need to be fleshed out a bit more, but essentially, it was an easy way to let a process to know what's happening in another process so it could react appropriately. The e2e tests are a good use-case, but not something I've looked into yet (in theory, the framework should hold up for it)
Original intent was just a hobby/side project. As it grew, I thought maybe posting about it would be alright in case people find the idea interesting.
lmao how is this on the front page at the 2 spot? People upvoting based on seeing buzzwords I assume? It's cool that small projects can get recognition here but this is not useful software
no idea, my project post moved down asap...a few little upvotes only.
I really liked the interactive app demo on the website. App looks good (features + polish) I have it downloaded, will check it out later tonight!
Oh, thank you!
It's still at the number two spot 30+ minutes later. That's wild.
There are upvote bots here, so any vibe coded project makes it to the front page.
So we get an abundance of (useless) software.
I've done a lot of things reusing/modifying the internals of alacritty [1] to put terminals in things. TeX in the terminal [2], a terminal in minecraft [3], Alacritty in Godot [4], and not pictured, alacritty in a swift plugin for macos/ios/ipados all at various levels of completion.
1. https://alacritty.org/
2. https://blog.fangorn.io/tex-in-terminal
3. https://anvil.fangorn.io/fangorn/huorn-minecraft
4. https://blog.fangorn.io/alacritty-in-godot
This is such a cursed combination... I really don't understand what you get from Godot that benefits you for building a TTY "multiplexer."
Wildly vibe-coded to the extent that it's more misguided than Doom on a pregnancy test...
Also looking at OP's notes here, there doesn't even seem to be a need for this to exist, "FPS counter" ..? Perhaps, I don't know, fake terminals on a spaceship or something. Yueash...
a note about "Doom on a preganancy test". It wasn't actually running on the pregnancy test. It was displayed on the tests 1 color LCD screen, but everything else was different hardware. It was a test of hacking the display and what it was capable of in cheap disposable device, not the processing power of the electronics in the test.
I went shopping for a 4K OLED pregnancy test with 3 HDMI ports, but they threw me out of the pharmacy
"more misguided than Doom on a pregnancy test" has been added to my lexicon.
AI fanatics love terminal multiplexers.
There's a new one every day posted on r/tmux
It’s like it was designed in a lab to maximize engagement on Reddit.
hammer meet nail