-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ghostty instead? #4353
Comments
What's wrong with the current terminal? |
Motivation is in OP:
From this thread: https://ziggit.dev/t/targeting-android/4101 it seems like compiling for android should be possible at least. Would be a large undertaking indeed! |
Watch the videos of ghostty or try it yourself now that it's open-source: it beats the pants off of most existing terminals, most of which will in turn be much faster and full-featured than Termux. I don't blame Fredrik for just grabbing this available Android terminal emulator when getting started, but a decade later, we'd be much better off making this app an Android shell around an existing terminal emulator library like that. The only drawback I see is that the zig language ghostty is written in is still in beta, so maybe its Android support still has holes. |
I thought it was time to sunset the app :p |
I thought you said it "isn't going away"? 😉 If you're going to keep working on it, here's a way to make it much better at minimal cost. |
"beats the pants off" might be accurate compared to some of the older VTE based terminals. The current implementation of Ghostty is also very heavily tied into GTK4 and Libadwaita. |
In essence, a new frontend needs to be written for libghostty and handle the Termux-specific implementation for running commands/executables - it may not necessarily come at minimal cost. |
Not according to them, from my link above, "reading a dump of plain text is 4x faster compared to iTerm and Kitty, and 2x faster than Terminal.app. Alacritty is very fast but we're still around the same speed (give or take) and our app experience is much more feature rich."
No, it works well on macOS too, using Swift and Metal for platform-specific code there. Since it's already fairly cross-platform, Android support would likely entail simply calling those same cross-platform methods from an Android app instead and maybe adjusting their OpenGL rendering backend for OpenGLES a bit.
We already have a fairly basic frontend written in Java here, you'd just swap out the emulation and rendering to an OpenGLES context run by ghostty instead.
You mean this small C++ file? Should be easy to integrate that with any changes, as you'd still need to keep the existing Java code that calls Android's Java-only APIs anyway. |
Feature description
It seems like they've done a lot of work to build a terminal app and renderer library in zig, maybe it would make more sense to make this app a thin Android shell around that library? I think it would be much faster and more full-featured than our current Java code.
Additional information
The only drawback I see is that I'm not sure how well zig currently supports Android, but it certainly seems a much better language than Java.
Obviously, this is not a decision to be taken lightly, so it would just depend on if major contributors to this repo like @agnostic-apollo and @fornwall want to do that work.
The text was updated successfully, but these errors were encountered: