#1123 added a warning when the OpenGL version is too old, but
it is never used because GTK enforces the version set with
gl_area.setRequiredVersion() before prepareContext() is called:
we end up with a generic "failed to make GL context" error:
warning(gtk_ghostty_surface): failed to make GL context current: Unable to create a GL context
warning(gtk_ghostty_surface): this error is almost always due to a library, driver, or GTK issue
warning(gtk_ghostty_surface): this is a common cause of this issue: https://ghostty.org/docs/help/gtk-opengl-context
This patch removes the requirement at the GTK level and lets the ghostty
renderer check, now failing as follow:
info(opengl): loaded OpenGL 4.2
error(opengl): OpenGL version is too old. Ghostty requires OpenGL 4.3
warning(gtk_ghostty_surface): failed to initialize surface err=error.OpenGLOutdated
warning(gtk_ghostty_surface): surface failed to initialize err=error.SurfaceError
(Note that this does not render a ghostty window, unlike the previous
error which rendered the "Unable to acquire an OpenGL context for
rendering." view, so while the error itself is easier to understand it
might be harder to view)
This is a subcommand I've been using for some time. It takes an optional
issue/PR number as context and produces a prompt to review a branch for
how well it addresses the issue along with any isolated issues it spots.
Example:
https://ampcode.com/threads/T-019b2877-475f-758d-ae88-93c722561576
This is a subcommand I've been using for some time. It takes an optional
issue/PR number as context and produces a prompt to review a branch for
how well it addresses the issue along with any isolated issues it spots.
Example: https://ampcode.com/threads/T-019b2877-475f-758d-ae88-93c722561576
Related Issue: #5047
Discussion: #4664
### Investigation
The behavior of iTerm mentioned on the Discussion thread was as follows:
- `cmd + u` can be used to toggle "Use Transparency"
- The "Use Transparency" toggle operates on a per-surface basis
- The "Use Transparency" state persists even after reloading the config
### Summary
Based on the investigation and discussions in the preceding pull
requests, this implements the `toggle_background_opacity` keybind action
for macOS with the following specifications:
- Switches background opacity on a per-surface basis
- The background opacity state persists even after reloading the config
- Background opacity switching functionality is also available in Quick
Terminal
- Does nothing if `background-opacity` is set to 1 or higher
- Does nothing if in fullscreen mode
### Verification
This functionality has been tested across following scenarios,
confirming correct action behavior for:
- Split Window
- Each split window maintains synchronized background opacity states
- Tab Group
- Background opacity states do not synchronize between tabs
- Quick Terminal
- Background opacity states remain synchronized even when windows are
closed
- Command Palette
### AI Disclosure
This pull request was made with assistance from Claude Code.
I reviewed all AI-generated code and wrote the final output manually.
https://github.com/user-attachments/assets/e46ff8f0-42f2-442f-97dd-d5f5c33b10f1
This PR fixes an issue #9563 where relative file paths were not being
resolved against the terminal’s current working directory before
opening.
#### Verification
Tested with directories containing:
```
/tmp/test/test
❯ du -h .
0B ./spaces-end
0B ./with dot.
0B ./space middle
8.0K .
```
Parent directory resolution also works as expected:
```
/tmp/test/test
❯ du -h ..
0B ../test/spaces-end
0B ../test/with dot.
0B ../test/space middle
8.0K ../test
16K ..
```
@mitchellh
In your original description you mentioned that “Links should work for all situations as they do in iTerm2.”
I noticed that, for example, when running `ls`, the paths are not clickable, while they are clickable in iTerm2.
If you think this case should also be handled, I can open a separate PR for it once this one is accepted.
Implements #8399.
I didn't save `position` in this pr, since I don't see its necessity.
Changing `quick-terminal-position` requires a relaunch; saving and
restoring this would have to deal with conflicts. I also don't see why a
user would change this frequently.
> [!NOTE]
> Used GPT to proofread my comments
This adds a couple optimizations to our CI:
1. macOS matrix gone, only test that freetype builds in addition to
Coretext.
2. Move Flatpak out to a triggered build on main similar to snaps. This
was our longest build and avoiding it in PRs is a win since it rarely
fails.
This changes our GHA that updates our color schemes to also upload it to
our dependency mirror at the same time. This prevents issues where the
upstream disappears, which we've had many times.
This disables a bunch of configurations that we don't need to actually
test for. The main one we want to keep building is Freetype because we
sometimes use this to compare behaviors, but Coretext is the default.
This is one of the primary drivers of CI CPU time.
This changes our GHA that updates our color schemes to also upload it
to our dependency mirror at the same time. This prevents issues where
the upstream disappears, which we've had many times.
I had a bit of the same annoyance as #9064. I agree that with balanced
padding, you should expect horizontal jitter when resizing horizontally,
and vertical jitter when resizing vertically. Diagonal jitter, however,
happened because the top padding was upper bounded by the left padding,
coupling the vertical and horizontal wobbling. This looks kind of janky,
and it's surprising that the balance between top and bottom padding
changes as you vary only the width of the window.
With this PR, the upper bound is instead equal to the maximum left
padding. Since this only depends on the config, not the current window
width, the diagonal wobbling is avoided. Both the top and left padding
still have the same range of motion as before.
An alternative could be to bound by the minimum or median left padding
instead. Open to suggestions.
**Before**
https://github.com/user-attachments/assets/d12c5870-f05d-450f-89fc-c59eab90e199
**After**
https://github.com/user-attachments/assets/35b80bb0-9ea2-41c1-8502-3a8eec51dbc6
## Description
This PR implements the basic functionality for "Liquid Glass" style
background support (#8155). I used OpenCode (Claude 4) in some capacity
to write this as I'm not super familiar with AppKit / SwiftUI. A good
chunk of this I still needed to write by hand since Claude doesn't
understand the Glass APIs, but I'm not 100% if the implementation here
makes the best decisions since the practices in Ghostty config and
separation of the AppKit code and SwiftUI seemed inconsistent to me.
Some of the combinations of options obviously create entirely unreadable
terminals, but I've found that regular glass and transparent with
opacity to be fairly readable. We *don't* enable this feature by default
since it would of course break existing users setups.
## Open Questions
- [x] How to determine the correct cornerRadius? For now this is
eyeballed, I can't see any macOS public API or clearly documented
constants.
- [x] Should boolean options be exposed for reasonable defaults?
- [x] Should the option need to be namespaced to macos-\*?
## Screenshots
0% Opacity, Regular
<img width="917" height="683" alt="image"
src="https://github.com/user-attachments/assets/ccb96ba7-5df2-4284-8526-e07bbb62e3e5"
/>
50% Opacity, Transparent
<img width="880" height="680" alt="image"
src="https://github.com/user-attachments/assets/5bdf12f9-3209-4aa9-8a4f-9a6eb4f95894"
/>
0% Opacity, Transparent
<img width="860" height="681" alt="image"
src="https://github.com/user-attachments/assets/1b33d400-4d8b-479a-94d7-47b844743e52"
/>
Reported by Mr. Hashimoto in discord.
These changes removedthe following warning:
`evaluation warning: 'system' has been renamed to/replaced by
'stdenv.hostPlatform.system'`
This adds a couple of Nix-based VM integration tests:
- Does `ghostty +version` run successfully?
- Can we create a new terminal window? (This is detected by setting the
background to a color that doesn't appear
normally on the desktop and seeing if we can detect that color in a
screenshot).
Obviously more can be done but I thought that these would be a couple of
good first steps.
The whole test suite can be run with `nix flake check`. Individual tests
can be run with a command like this:
```
nix run .#check.x86_64-linux.<test name>.driver
```
