We need this to get info about the padding, even if we do derive the
grid and screen size separately.
In the future this should possibly be changed to a message that only
sends the padding info and nothing else.
If this was Swift code, we'd be using a strong reference, which would
retain the layer for us and release it when the object is deallocated,
but this is Zig land so we have to do that manually.
NOTE: We don't *have* to do this, but it fits much better with Zig idiom
and hopefully avoids potential future footguns. We should do this to any
autoreleased objects that we persist a reference to in a Zig struct.
This commit is very large, representing about a month of work with many
interdependent changes that don't separate cleanly in to atomic commits.
The main change here is unifying the renderer logic to a single generic
renderer, implemented on top of an abstraction layer over OpenGL/Metal.
I'll write a more complete summary of the changes in the description of
the PR.
This PR makes the build script use the correct SDK and version flag for
the iOS Simulator.
Without this PR, the terminal fails to initialize on the iOS Simulator:
```
Compiler failed to build request
metal error=Target OS is incompatible: library was not compiled for the simulator
error initializing surface err=error.MetalFailed
```
<details>
<summary>With the PR</summary>
</details>
Fixes#7635.
This wasn't working before but it just requires a restart of the machine
for the changes to take effect. The namespace runners have this prebuilt
so this should work now.
The other workaround was flaky for unknown reasons so I'd prefer to go
back to this.
This fixes an issue where pressing the red close button in a window or
the "x" button on a tab couldn't differentiate and would always close
the tab or close the window (depending on tab counts).
It seems like in both cases, AppKit triggers the `windowShouldClose`
delegate method on the controller, but for the close window case it
triggers this on ALL the windows in the group, not just the one that was
clicked.
I implemented a kind of silly coordinator that debounces
`windowShouldClose` calls over 100ms and uses that to differentiate
between the two cases.
This wasn't working before but it just requires a restart of the machine
for the changes to take effect. The namespace runners have this prebuilt
so this should work now.
The other workaround was flaky for unknown reasons so I'd prefer to go
back to this.
This fixes an issue where pressing the red close button in a window or
the "x" button on a tab couldn't differentiate and would always close
the tab or close the window (depending on tab counts).
It seems like in both cases, AppKit triggers the `windowShouldClose`
delegate method on the controller, but for the close window case it
triggers this on ALL the windows in the group, not just the one
that was clicked.
I implemented a kind of silly coordinator that debounces
`windowShouldClose` calls over 100ms and uses that to differentiate
between the two cases.
Resolves#7591
This moves our CI to build macOS on Sequoia (macOS 15) with Xcode 26,
including the new macOS 26 beta SDK. This includes tip releases. Stable
releases continue to use Xcode 15 and the stable SDK, in case we need to
make a release before macOS Tahoe is stable (though, if its late enough
in the cycle, we may even cut a full release with it).
Importantly, this will make our builds on macOS 26 use the new styling.
I've added a new job that ensures we can continue to build with Xcode 16
and the macOS 15 SDK, as well, although I think that might come to an
end when we switch over to an IconComposer-based icon. I'll verify then.
For now, we continue to support both.
I've also removed our `hasLiquidGlass` check, since this will now always
be true for macOS 26 builds.
Resolves#7591
This moves our CI to build macOS on Sequoia (macOS 15) with Xcode 26,
including the new macOS 26 beta SDK.
Importantly, this will make our builds on macOS 26 use the new styling.
I've added a new job that ensures we can continue to build with Xcode 16 and
the macOS 15 SDK, as well, although I think that might come to an end
when we switch over to an IconComposer-based icon. I'll verify then. For
now, we continue to support both.
I've also removed our `hasLiquidGlass` check, since this will now always
be true for macOS 26 builds.
We were depending on $GHOSTTY_RESOURCES_DIR for two reasons:
1. To locate our script-adjacent bash-preexec.sh script
2. To restrict our script's execution to environments in which
$GHOSTTY_RESOURCES_DIR is available (i.e. Ghostty-only shells)
For (1), we can instead determine our directory using $BASH_SOURCE[0].
This is slightly differently than our previous behavior, where we'd
always load bash-preexec.sh from the $GHOSTTY_RESOURCES_DIR hierarchy,
even if ghostty.bash from source from somewhere else on the file system
... but we never relied on that behavior, even in development.
For (2), there's no harm in source'ing this script outside of Ghostty,
and if that does become a concern, we can restore this condition or use
something more targeted based on those specific cases.
Historically, I believe (2) was in place to enable (1), so addressing
(1) removes the need for (2).
And lastly, none of the other shell integration scripts depend on
$GHOSTTY_RESOURCES_DIR.
We were depending on $GHOSTTY_RESOURCES_DIR for two reasons:
1. To locate our script-adjacent bash-preexec.sh script
2. To restrict our script's execution to environments in which
$GHOSTTY_RESOURCES_DIR is available (i.e. Ghostty-only shells)
For (1), we can instead determine our directory using $BASH_SOURCE[0].
This is slightly differently than our previous behavior, where we'd
always load bash-preexec.sh from the $GHOSTTY_RESOURCES_DIR hierarchy,
even if ghostty.bash from source from somewhere else on the file system
... but we never relied on that behavior, even in development.
For (2), there's no harm in source'ing this script outside of Ghostty,
and if that does become a concern, we can restore this condition or use
something more targeted based on those specific cases.
Historically, I believe (2) was in place to enable (1), so addressing
(1) removes the need for (2).
And lastly, none of the other shell integration scripts depend on
$GHOSTTY_RESOURCES_DIR.
This integrates with macOS accessibility APIs to expose Ghostty terminal
structure and content.
This is a very, very bare implementation and the terminal contents
currently reported are the _full screen and scrollback_ which is way too
much for realistic human accessibility use. The target use case for this
PR is to enable automated tooling (namely, AI screen readers). However,
this is all groundwork we'll need to iterate and improve the
accessibility work anyways.
To make this work, I also replatformed some of our hacky C APIs onto a
more robust `ghostty_surface_read_text` API that can now read arbitrary
ranges of the screen into C strings for consumers to use. This will be
useful in more places going forward (hint hint).
## Before
Accessibility tooling can't read anything, Ghostty has no attributes, no
contents, just shows up as a square.
## After
A lot of metadata, including the screen contents as text.
Also, split hierarchies are navigable:
https://github.com/user-attachments/assets/a7b2ffb7-dbeb-41b2-8705-9c3200812c4d
This fixes a regression from our Tahoe window styling changes on
earlier, stable versions of macOS. We need to set
"titlebarAppearsTransparent" to true in order to hide the bottom border.
This fixes a regression from our Tahoe window styling changes on
earlier, stable versions of macOS. We need to set
"titlebarAppearsTransparent" to true in order to hide the bottom
border.
This is recommended for macOS Tahoe and all standard menu items now have
associated images. This makes our app look more polished and native for
macOS Tahoe.
On earlier versions of macOS (macOS 15 and earlier), we _do not_ set the
menu item image. Cocoa has supported menu item images for a long time
but it isn't idiomatic to show them in earlier versions, so we only do
this for later macOS versions.
For icon choice, I tried to copy other native macOS apps as much as
possible, mostly from Xcode. It looks like a lot of apps aren't updated
yet. I'm absolutely open to suggestions for better icons but I think
these are a good starting point.
One menu change is I moved "reset font size" above "increase font size"
which better matches other apps (e.g. Terminal.app).
https://github.com/user-attachments/assets/50a68326-221f-454f-9a9c-078878010a63
This is recommended for macOS Tahoe and all standard menu items now have
associated images. This makes our app look more polished and native for
macOS Tahoe.
For icon choice, I tried to copy other native macOS apps as much as
possible, mostly from Xcode. It looks like a lot of apps aren't updated
yet. I'm absolutely open to suggestions for better icons but I think
these are a good starting point.
One menu change is I moved "reset font size" above "increase font size"
which better matches other apps (e.g. Terminal.app).
