Skip to content
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

Open
finagolfin opened this issue Jan 15, 2025 · 8 comments
Open

Use ghostty instead? #4353

finagolfin opened this issue Jan 15, 2025 · 8 comments

Comments

@finagolfin
Copy link
Member

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.

@n-ce
Copy link

n-ce commented Jan 22, 2025

What's wrong with the current terminal?

@Grimler91
Copy link
Member

What's wrong with the current terminal?

Motivation is in OP:

it would be much faster and more full-featured

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!

@finagolfin
Copy link
Member Author

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.

@agnostic-apollo
Copy link
Member

I thought it was time to sunset the app :p

@finagolfin
Copy link
Member Author

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.

@TomJo2000
Copy link
Member

TomJo2000 commented Jan 22, 2025

"beats the pants off" might be accurate compared to some of the older VTE based terminals.
But against something like alacritty, foot, kitty, konsole or wezterm it's just another good option, I am interested to see where it's going but until both it (e.g. libghostty) and Zig mature some more I don't think it's time consider to replace our existing terminal code.

The current implementation of Ghostty is also very heavily tied into GTK4 and Libadwaita.
So it beats the pants off any other terminal made for GNOME, but outside of that narrow context it's iffy.

@ongyx
Copy link

ongyx commented Jan 22, 2025

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.

@finagolfin
Copy link
Member Author

against something like alacritty, foot, kitty, konsole or wezterm it's just another good option

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."

The current implementation of Ghostty is also very heavily tied into GTK4 and Libadwaita.

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.

a new frontend needs to be written for libghostty

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.

handle the Termux-specific implementation for running commands/executables - it may not necessarily come at minimal cost

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants