> The only UI Ghostty has is tabs and the context menu
- Tabs
- Splits
- "this process has exited" banner
- Close confirmation dialogs
- Change title dialog
- Unsafe paste detection dialogs
- Context menus
- Animated bells (opt in)
- "Quake-style" dropdown terminals (cross platform but different mechanisms)
- Progress bars (ConEmu OSC 9;4)
- macOS: Apple Shortcuts Integration
- macOS: Spotlight Integration
Probably more I'm not thinking of. It's unfair to say it's just tabs. Could we have done this without a GUI toolkit? Of course! But the whole mission statement of this project was always to use platform-native (for various definitions) toolkits so that it _feels_ native.
That's not for everyone, and that's the great thing about the wonderful vibrant terminal ecosystem we have.
> is it really worth the integration pain and now this rewrite?
There's definitely a lot more on the way.
The first goal and primary focus of the project was to build a stable, feature rich (terminal sequences) terminal emulator. We're basically there. Next up, we're expanding GUI functionality significantly, including having more escape sequences result in more native GUI elements. But also traditional things like preferences GUIs, yes.
We're also integrating a lot more deeply with native features provided by each platform (somewhat related to the GUI toolkit choice), such as automatic iCloud syncing of your configuration on macOS. Now that the terminal is stable, we can start to really lean in to application features.
This isn't for everyone. Some people like Kitty's textual tabs. That's fine! It's a tradeoff. That's the beauty of choice. :) Kitty is a great terminal, if you prefer it, please use it. But it has completely different tradeoffs than Ghostty.
I know I'm about to show my ignorance regarding GUI programming here, but: would SDL2 be a suitable choice? Or would that be too low-level? Or just...the wrong sort of library?
SDL2 wouldn't be appropriate for what they're trying to do.
SDL2 is more of a drawing and graphics library. You tell it to put a triangle here, it puts a triangle there. But it has no idea what a button should look like - how it should behave, how it should be animated - on Mac, on Windows, on KDE, on Gnome, etc. You could try to painstakingly recreate this look and feel for each platform, but it's a lot of effort, you probably won't get it quite right, you'll make oversights on accessibility and internationalisation, and your hard work will instantly look dated once the platform evolves.
To make native GUIs, you need to talk to the libraries that draw platform-native components, like buttons, for you. But of course each platform works totally differently, and the whole affair is honestly kind of a mess, which is why truly native cross-platform applications tend to be fairly rare in practice. Maintaining five different GUI code bases for all sorts of fringe platforms is not, in most cases, a good use of time. For most apps, either you stick to native and cut less significant platforms, or you abandon native altogether and just use a cross-platform wrapper like Electron.
Just from my basic understanding after working with sdl2 and gtk, sdl2 is more suitable for game development, It doesn't have standard set of UI elements. So every UI element, and interactions will have to be implemented by hand. Now imagine displaying a list view with huge number of items.
And the worst is, Terminals works with texts, sdl2, in my knowledge do not have proper way to display large amount of text, let alone select and copy.
There are probably other issues, these came from what I experienced
Unless you plan on writing your entire UI from scratch, like, from the framebuffer on up (in which case it will integrate poorly with the rest of the desktop) you must use one of the common widget toolkits: GTK or Qt. If you want the flexibility of not having to commit to C++, GTK is your only choice.
- Tabs
- Splits
- "this process has exited" banner
- Close confirmation dialogs
- Change title dialog
- Unsafe paste detection dialogs
- Context menus
- Animated bells (opt in)
- "Quake-style" dropdown terminals (cross platform but different mechanisms)
- Progress bars (ConEmu OSC 9;4)
- macOS: Apple Shortcuts Integration
- macOS: Spotlight Integration
Probably more I'm not thinking of. It's unfair to say it's just tabs. Could we have done this without a GUI toolkit? Of course! But the whole mission statement of this project was always to use platform-native (for various definitions) toolkits so that it _feels_ native.
That's not for everyone, and that's the great thing about the wonderful vibrant terminal ecosystem we have.
> is it really worth the integration pain and now this rewrite?
There's definitely a lot more on the way.
The first goal and primary focus of the project was to build a stable, feature rich (terminal sequences) terminal emulator. We're basically there. Next up, we're expanding GUI functionality significantly, including having more escape sequences result in more native GUI elements. But also traditional things like preferences GUIs, yes.
We're also integrating a lot more deeply with native features provided by each platform (somewhat related to the GUI toolkit choice), such as automatic iCloud syncing of your configuration on macOS. Now that the terminal is stable, we can start to really lean in to application features.
This isn't for everyone. Some people like Kitty's textual tabs. That's fine! It's a tradeoff. That's the beauty of choice. :) Kitty is a great terminal, if you prefer it, please use it. But it has completely different tradeoffs than Ghostty.