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'll be honest with you: I'm not going to use what you have made. I don't mean that offensively, it's just not what I want to use for my workflow. Keep making tools you enjoy using though. That's the spirit of the computer.
That said, for your browser problem, what if you embed the browser inside of godot? Chromium embedded framework does this. I was able to get this to work for me to see Chrome inside of my godot exported projects. https://github.com/dsh0416/godot-cef I believe this is only for desktop exports though, no html5/mobile builds.
Only downside is you have to use Chromium ;)
* putting a quick note in here-- godot-cef is not my project
Thanks for your honest response. It's okay. At its core, it's a fun hobby/side project, not my day job. And I like it. But I'm realizing maybe this wasn't the platform to post on.
The browser is probably a non-issue, more a passing thought now. I definitely do not want to bundle or bring in Chromium. If it was a deal-breaker, I would've just gone the Electron route. Appreciate you sharing your WebView extension though, looks neat!
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.
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 is something I should've also added to the README.
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.
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 wanted to share my side-project: gPTY. Started off as an idea to combine Godot and Rust in a project (two stacks I wanted to use more to learn more). The base inspiration was tmux - simply allow spawning multiple PTYs and then let the user grid/tile them how they see fit.
But since we have the Godot game engine at our disposal, we can do some more interesting things, like add an FPS counter, and then subsequently also let people set their preferred FPS (the idea being the potential lower power draw if someone's running it on a laptop on battery power vs someone running it on a desktop with high/native FPS). In its current state, with me using Oh-my-Pi a lot, it's evolving into a terminal workspace that can be used for orchestrating autonomous AI agents by way of dogfooding (or you know, just run herdr inside of gPTY - it's the better orchestrator and just good software - I found it after starting this project, and now I'm finding myself using it a lot).
Also, we're not limited to just terminals. Since we have Godot, we have basically a 2D (and potentially a 3D) canvas to play with. We can already full-screen the app for "zen" mode, no taskbar, no distractions. TUI die-hards can have their media or other apps entirely in terminal panes.
There has been some ground-work on getting Markdowns displayed properly done and I want to work on some kind of Wiki framework for local knowledge-management next, then create more types of panes (think native audio/video on a media pane, that sits alongside your terminal pane), and some simple 2D games (like snake) to prototype. More details are on the ROADMAP.
What's not easy (and probably won't happen) is a browser. Having done a couple of (small) projects using Electron already, the temptation to ditch Godot/Rust (learning curve) did come up (and also the ecosystem, the ease with which I could pull components and use web technologies - development velocity would definitely be higher there). But on the flipside, given all of the available LLM and AI support that we are privileged to have today, I figured the velocity should be comparable depending on how much I leaned on those. And lean I did.
Godot/Rust seemed the better call to me and my intent anyway - going with the 'it's not just the end but the journey that matters' philosophy. So yes, there has been heavy use of LLMs & AI to generate a lot of the code. But I do review and steer actively, not relying solely on vibes, and there's a few bits here & there that have been human authored.
There are definitely a lot of polish and QoL items that need to land to make the end user experience better, but in the meantime, let me know your thoughts and/or concerns!
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...
There's a new one every day posted on r/tmux
That said, for your browser problem, what if you embed the browser inside of godot? Chromium embedded framework does this. I was able to get this to work for me to see Chrome inside of my godot exported projects. https://github.com/dsh0416/godot-cef I believe this is only for desktop exports though, no html5/mobile builds.
Only downside is you have to use Chromium ;)
* putting a quick note in here-- godot-cef is not my project
The browser is probably a non-issue, more a passing thought now. I definitely do not want to bundle or bring in Chromium. If it was a deal-breaker, I would've just gone the Electron route. Appreciate you sharing your WebView extension though, looks neat!
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 is something I should've also added to the README.
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.
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.
So we get an abundance of (useless) software.
But since we have the Godot game engine at our disposal, we can do some more interesting things, like add an FPS counter, and then subsequently also let people set their preferred FPS (the idea being the potential lower power draw if someone's running it on a laptop on battery power vs someone running it on a desktop with high/native FPS). In its current state, with me using Oh-my-Pi a lot, it's evolving into a terminal workspace that can be used for orchestrating autonomous AI agents by way of dogfooding (or you know, just run herdr inside of gPTY - it's the better orchestrator and just good software - I found it after starting this project, and now I'm finding myself using it a lot).
Also, we're not limited to just terminals. Since we have Godot, we have basically a 2D (and potentially a 3D) canvas to play with. We can already full-screen the app for "zen" mode, no taskbar, no distractions. TUI die-hards can have their media or other apps entirely in terminal panes.
There has been some ground-work on getting Markdowns displayed properly done and I want to work on some kind of Wiki framework for local knowledge-management next, then create more types of panes (think native audio/video on a media pane, that sits alongside your terminal pane), and some simple 2D games (like snake) to prototype. More details are on the ROADMAP.
What's not easy (and probably won't happen) is a browser. Having done a couple of (small) projects using Electron already, the temptation to ditch Godot/Rust (learning curve) did come up (and also the ecosystem, the ease with which I could pull components and use web technologies - development velocity would definitely be higher there). But on the flipside, given all of the available LLM and AI support that we are privileged to have today, I figured the velocity should be comparable depending on how much I leaned on those. And lean I did.
Godot/Rust seemed the better call to me and my intent anyway - going with the 'it's not just the end but the journey that matters' philosophy. So yes, there has been heavy use of LLMs & AI to generate a lot of the code. But I do review and steer actively, not relying solely on vibes, and there's a few bits here & there that have been human authored.
There are definitely a lot of polish and QoL items that need to land to make the end user experience better, but in the meantime, let me know your thoughts and/or concerns!
Repository: https://github.com/godot-pty/gpty
Docs/Blog: https://godot-pty.github.io/gpty/