This deletes the GLFW apprt from the Ghostty codebase.
The GLFW apprt was the original apprt used by Ghostty (well, before
Ghostty even had the concept of an "apprt" -- it was all just a single
application then). It let me iterate on the core terminal features,
rendering, etc. without bothering about the UI. It was a good way to get
started. But it has long since outlived its usefulness.
We've had a stable GTK apprt for Linux (and Windows via WSL) and a
native macOS app via libghostty for awhile now. The GLFW apprt only
remained within the tree for a few reasons:
1. Primarily, it provided a faster feedback loop on macOS because
building the macOS app historically required us to hop out of the
zig build system and into Xcode, which is slow and cumbersome.
2. It was a convenient way to narrow whether a bug was in the
core Ghostty codebase or in the apprt itself. If a bug was in both
the glfw and macOS app then it was likely in the core.
3. It provided us a way on macOS to test OpenGL.
All of these reasons are no longer valid. Respectively:
1. Our Zig build scripts now execute the `xcodebuild` CLI directly and
can open the resulting app, stream logs, etc. This is the same
experience we have on Linux. (Xcode has always been a dependency of
building on macOS in general, so this is not cumbersome.)
2. We have a healthy group of maintainers, many of which have access
to both macOS and Linux, so we can quickly narrow down bugs
regardless of the apprt.
3. Our OpenGL renderer hasn't been compatible with macOS for some time
now, so this is no longer a useful feature.
At this point, the GLFW apprt is just a burden. It adds complexity
across the board, and some people try to run Ghostty with it in the real
world and get confused when it doesn't work (it's always been lacking in
features and buggy compared to the other apprts).
So, it's time to say goodbye. Its bittersweet because it is a big part
of Ghostty's history, but we've grown up now and it's time to move on.
Thank you, goodbye.
(NOTE: If you are a user of the GLFW apprt, then please fork the project
prior to this commit or start a new project based on it. We've warned
against using it for a very, very long time now.)
`zig build run` on macOS now builds the app bundle via the `xcodebuild`
CLI and runs it. The experience for running the app is now very similar
to Linux or the prior GLFW build, where the app runs, blocks the zig
command, and logs to the terminal.
`xcodebuild` has its own build cache system that we can't really hook
into so it runs on every `zig build run` command, but it does cache and
I find its actually relatively fast so I think this is a good
replacement for the glfw-based system.
Fixes#7794
This commit also resets some terminal state to give us a better chance
of getting an encoded key, such as ensuring keyboard input is enabled
and disabling any Kitty protocols. This shouldn't ever be set but just
in case!
This fixes an Apple Shortcuts crash for macOS 15 and earlier.
Unfortunately it looks like we can't guard these with `@available`. I'm
going to report an Apple Feedback about this but for now this gets
shortcuts working on macOS 15 and earlier.
Fixes#7794
This commit also resets some terminal state to give us a better chance
of getting an encoded key, such as ensuring keyboard input is enabled
and disabling any Kitty protocols. This shouldn't ever be set but just
in case!
This fixes an Apple Shortcuts crash for macOS 15 and earlier.
Unfortunately it looks like we can't guard these with `@available`. I'm
going to report an Apple Feedback about this but for now this gets
shortcuts working on macOS 15 and earlier.
Fixes#7792
Our error handling for `exec` failing within the forked process never
actually worked! It triggered all sorts of issues. We didn't catch this
before because it used to be exceptionally hard to fail an exec because
we used to wrap ALL commands in a `/bin/sh -c`.
However, we now support direction execution, most notably when you do
`ghostty -e <command>` but also via the `direct:` prefix on configured
commands.
This fixes up our exec failure handling by printing a useful error
message and avoiding any errdefers in the child which was causing the
double-close.
Fixes#7792
Our error handling for `exec` failing within the forked process never
actually worked! It triggered all sorts of issues. We didn't catch this
before because it used to be exceptionally hard to fail an exec because
we used to wrap ALL commands in a `/bin/sh -c`.
However, we now support direction execution, most notably when you do
`ghostty -e <command>` but also via the `direct:` prefix on configured
commands.
This fixes up our exec failure handling by printing a useful error
message and avoiding any errdefers in the child which was causing the
double-close.
Fixes#7786
Fixes regression from #7683
This is a band-aid fix. The issue is that performable keybinds don't
show up in the reverse mapping that GUI toolkits use to find their key
equivalents. The full explanation of why is already in Binding.zig.
For macOS, we have a way to validate menu items before they're triggered
so we ideally do want a way to get reverse mappings even with
performable keybinds. But I think this wants to be optional and that's
all a bigger change. For now, this is a simple fix that will work.
Fixes#7786
Fixes regression from #7683
This is a band-aid fix. The issue is that performable keybinds don't
show up in the reverse mapping that GUI toolkits use to find their key
equivalents. The full explanation of why is already in Binding.zig.
For macOS, we have a way to validate menu items before they're triggered
so we ideally do want a way to get reverse mappings even with
performable keybinds. But I think this wants to be optional and that's
all a bigger change. For now, this is a simple fix that will work.
Discussed in #7714, fix confirmed by user as working.
Okay, so, what the hell? This implies that on this user's system,
something that *should* be an integer multiple of the cell width, when
divided by the cell width, is giving some epsilon less than the proper
result. I can only guess that this is driver or hardware weirdness,
possibly the fragcoord is being converted from a low precision float in
NDC to the fragment-space coordinate so we're not actually getting an
integer multiple, and the epsilon less is actually before the division?
Regardless, switching it back to use halves for pixel coordinates fixes
this and shouldn't break the math at all, since `floor((n * k + 0.5)/k)`
should always yield `n` just like without the `+ 0.5`.
Implemented cell color for Metal
Removed use of selection-invert-fg-bg
Mirrored feature to OpenGL
Added tests for SelectionColor
Fixed selection on inverted cell behavior
Implemented cell colors for cursor-text
Implemented cell colors for cursor-color, removed uses of cursor-invert-fg-bg during rendering
Updated docs for dynamically colored options
Updated docstrings, cleaned up awkward formatting, and moved style computation to avoid unnecssary invocations
Bump version in docstrings
By using integers for the fragcoords I may have stepped on an edge case
which causes cell background positions to be shifted by 1 px under some
circumstances. I couldn't reproduce that issue in a VM, so I'm making
this commit for the user who was having the problem to test it.
This PR contains fixes for 4 different memory leaks that affected
Ghostty on macOS.
1. (whenever a font is loaded) CoreText font features dict list wasn't
properly released. Fixed by releasing.
2. (whenever a font is searched for) CoreText discovery iterator
descriptors weren't properly released. Fixed by releasing.
3. (during resize) Metal texture descriptors were not properly released.
Fixed by releasing.
4. (every frame) Objective-C runtime blocks for buffer completion
handler and IOSurfaceLayer set surface were not properly deallocated due
to issues with the internal implementation in `zig-objc`. Fixed in
`zig-objc`, dependency hash updated with fix.
A handful of small apparent leaks remain but their cause is not clear
and they're all static (not increasing over time, seemingly).
### Xcode memory graph "leaks" comparison
|Before (main)|After (this PR)|
|-|-|
|<img width="445" alt="image"
src="https://github.com/user-attachments/assets/d1c89918-8ab2-4201-bf1e-9b3a519a85a8"
/>|<img width="445" alt="image"
src="https://github.com/user-attachments/assets/88c60807-756e-48d8-9918-2a52d6556035"/>|
<sup>Images taken after launching Ghostty, creating 4 tabs, and rapidly
switching between them to force render many frames.</sup>
---
Hopefully this fixes the occasional OOM issues some users have reported.
This update also fixes a memory leak that was caused by blocks not being
deallocated and just collecting every single frame, slowly accumulating
memory until OOM.
This will allow users to enable Ghostty startup on login. Users will
need to explicitly enable startup on login via this command:
```sh
systemctl enable --user com.mitchellh.ghostty.service
```
This is done at the apprt-level for a couple reasons.
(1) For libghostty, we don't have a way to know what the embedding
application is doing, so its risky to create signal handlers that
might overwrite the application's signal handlers.
(2) It's extremely messy to deal with signals and multi-threading.
Apprts have framework access that handles this for us.
For GTK, we use g_unix_signal_add.
For macOS, we use `DispatchSource.makeSignalSource`. This is an awkward
API but made for this purpose.
This is done at the apprt-level for a couple reasons.
(1) For libghostty, we don't have a way to know what the embedding
application is doing, so its risky to create signal handlers that
might overwrite the application's signal handlers.
(2) It's extremely messy to deal with signals and multi-threading.
Apprts have framework access that handles this for us.
For GTK, we use g_unix_signal_add.
For macOS, we use `DispatchSource.makeSignalSource`. This is an awkward
API but made for this purpose.
Introduces `fill`, which fills between two `Fraction`s, use this instead
of `yHalfs` and friends wherever they're used, which also means we can
remove `rect`.
This commit does change alignment of the vertical/horizontal eighths in
certain cell sizes, but the change is for the better IMO. Also changes
the center-point alignment of smooth mosaics for odd cell widths, but
the change is no more than half a pixel at worst and is probably an
improvement ultimately.
This will allow users to enable Ghostty startup on login. Users will
need to explicitly enable startup on login via this command:
```sh
systemctl enable --user com.mitchellh.ghostty.service
```
I've included a compatibility test here to make sure that the numbers
from this are in line with the numbers produced by xHalfs, yThirds, etc.
After this commit I'll introduce a helper function that fills based on a
span specified with this enum to replace any uses of xHalfs and friends.
Once I do that I'll remove them and the compatibility test, this should
be a much cleaner interface for this and make it easier to consistently
align block elements with each other.
Use `xHalfs` and `yHalfs` so that the dimensions of each quadrant are
appropriately aligned with block elements like the one half block, which
could be 1px taller than the bottom quadrants before this change.
This is in line with what we do for sextants, the fact that on odd-sized
cells there's a 1px overlap is considered acceptable there so I assume
it's acceptable here too.
- Large rework of how we draw sprite font glyphs, explained in the
commit message and comments.
- Adds separated block sextants from symbols for legacy computing
supplement
- Adds explicit underline cursor instead of using underline glyph for
it, resolves#7651, supersedes #7685
Currently we support these glyphs with the sprite font:
```
─━│┃┄┅┆┇┈┉┊┋┌┍┎┏┐┑┒┓└┕┖┗┘┙┚┛├┝┞┟┠┡┢┣┤┥┦┧┨┩┪┫┬┭┮┯┰┱┲┳┴┵┶┷┸┹┺┻┼┽┾┿╀╁╂╃╄╅╆╇╈╉╊╋╌╍╎╏═║╒╓╔╕╖╗╘╙╚╛╜╝╞╟╠╡╢╣╤╥╦╧╨╩╪╫╬╭╮╯╰╱╲╳╴╵╶╷╸╹╺╻╼╽╾╿▀▁▂▃▄▅▆▇█▉▊▋▌▍▎▏▐░▒▓▔▕▖▗▘▙▚▛▜▝▞▟◢◣◤◥◸◹◺◿⠀⠁⠂⠃⠄⠅⠆⠇⠈⠉⠊⠋⠌⠍⠎⠏⠐⠑⠒⠓⠔⠕⠖⠗⠘⠙⠚⠛⠜⠝⠞⠟⠠⠡⠢⠣⠤⠥⠦⠧⠨⠩⠪⠫⠬⠭⠮⠯⠰⠱⠲⠳⠴⠵⠶⠷⠸⠹⠺⠻⠼⠽⠾⠿⡀⡁⡂⡃⡄⡅⡆⡇⡈⡉⡊⡋⡌⡍⡎⡏⡐⡑⡒⡓⡔⡕⡖⡗⡘⡙⡚⡛⡜⡝⡞⡟⡠⡡⡢⡣⡤⡥⡦⡧⡨⡩⡪⡫⡬⡭⡮⡯⡰⡱⡲⡳⡴⡵⡶⡷⡸⡹⡺⡻⡼⡽⡾⡿⢀⢁⢂⢃⢄⢅⢆⢇⢈⢉⢊⢋⢌⢍⢎⢏⢐⢑⢒⢓⢔⢕⢖⢗⢘⢙⢚⢛⢜⢝⢞⢟⢠⢡⢢⢣⢤⢥⢦⢧⢨⢩⢪⢫⢬⢭⢮⢯⢰⢱⢲⢳⢴⢵⢶⢷⢸⢹⢺⢻⢼⢽⢾⢿⣀⣁⣂⣃⣄⣅⣆⣇⣈⣉⣊⣋⣌⣍⣎⣏⣐⣑⣒⣓⣔⣕⣖⣗⣘⣙⣚⣛⣜⣝⣞⣟⣠⣡⣢⣣⣤⣥⣦⣧⣨⣩⣪⣫⣬⣭⣮⣯⣰⣱⣲⣳⣴⣵⣶⣷⣸⣹⣺⣻⣼⣽⣾⣿🬀🬁🬂🬃🬄🬅🬆🬇🬈🬉🬊🬋🬌🬍🬎🬏🬐🬑🬒🬓🬔🬕🬖🬗🬘🬙🬚🬛🬜🬝🬞🬟🬠🬡🬢🬣🬤🬥🬦🬧🬨🬩🬪🬫🬬🬭🬮🬯🬰🬱🬲🬳🬴🬵🬶🬷🬸🬹🬺🬻🬼🬽🬾🬿🭀🭁🭂🭃🭄🭅🭆🭇🭈🭉🭊🭋🭌🭍🭎🭏🭐🭑🭒🭓🭔🭕🭖🭗🭘🭙🭚🭛🭜🭝🭞🭟🭠🭡🭢🭣🭤🭥🭦🭧🭨🭩🭪🭫🭬🭭🭮🭯🭰🭱🭲🭳🭴🭵🭶🭷🭸🭹🭺🭻🭼🭽🭾🭿🮀🮁🮂🮃🮄🮅🮆🮇🮈🮉🮊🮋🮌🮍🮎🮏🮐🮑🮒🮔🮕🮖🮗🮘🮙🮚🮛🮜🮝🮞🮟🮠🮡🮢🮣🮤🮥🮦🮧🮨🮩🮪🮫🮬🮭🮮🮯🮽🮾🮿
```
Screenshot:
<img width="1121" alt="image"
src="https://github.com/user-attachments/assets/d0979bf0-f585-415b-bbc7-b7b399adce25"
/>
I plan on doing a follow-up PR with a lot of new supported glyphs now
that it's so much easier to add them.
This pull request adds Korean translations.
I do want to add that while I do speak Korean _I am not a native
speaker_. I've done my best to provide translations as natural as
possible, but I'd love it if a native speaker could improve it before
merging.
