10644 Commits

Author SHA1 Message Date
Mitchell Hashimoto
c1c3f639c5 macos: Ghostty Icon Update for macOS Tahoe
This updates the Ghostty icon to be compatible with macOS Tahoe
(supports glass effects, light/dark, tinting, etc.). This icon is made
in the new Apple Icon Composer as the source format, and all other
formats are exported from it.

This commit also updates the icon for non-Apple platforms because the
icon is fundamentally the same and I don't see any reason to maintain
multiple icons of fundamentally the same design and style.

This commit also includes updates to the macOS app so that the About
Window and so on will use the new icon.
2025-06-21 12:34:49 -07:00
Mitchell Hashimoto
6fe72db0c4 macOS: App Intents (#7634)
This PR integrates Ghostty on macOS with the [App
Intents](https://developer.apple.com/documentation/appintents) system.
The focus of this initial work was on enabling [Apple
Shortcuts](https://support.apple.com/guide/shortcuts/welcome/ios) on
macOS, but App Intents are the same underlying system that powers a
number of other Apple features such as Spotlight, Siri, Widgets, and
more. We don't do much with these latter ones yet, though.

Additionally, this PR begins to refactor and untangle some of our
libghostty API calls from macOS views. Presently, macOS views and view
controllers directly call into the libghostty API and own libghostty
data models. This tight coupling is kind of nasty because it tends to
also couple libghostty API calls to the main GUI thread when they don't
really have to be (they just have to not be concurrently accessed). This
becomes an issue because App Intents run on background threads. This PR
starts to extract out some of this business logic into standalone
classes, but we still force all execution onto the main thread during
the transition.

**Version requirement:** Most of the shortcuts will work on macOS 13,
but there are some that require macOS 14, and some functionality will
require macOS 26. We gracefully degrade in all scenarios (the
capabilities that are unavailable just don't show up on older systems).

> [!IMPORTANT]
>
> This bumps our build requirements on macOS to Xcode 26 and the macOS
26 SDK. **You can still build on macOS 15,** but you must be using the
Xcode 26 beta. This includes a README update about that.

## Why?

Apple Shortcuts is an extremely powerful scripting tool on Apple
platforms. It comes with a number of built-in capabilities such as
moving windows, taking screenshots, fetching secrets, and more. By
integrating with Apple Shortcuts, it allows Ghostty to become scriptable
to a certain extent while also being able to take advantage of this
large ecosystem.

It is a huge downside that Shortcuts is Apple-only and I still would
like to make Ghostty scriptable to some extent on Linux and other
platforms as well. This work doesn't preclude that goal, but gives us an
answer to a large subset of users (macOS users), which is great.

Beyond this, no terminals integrate with Apple Shortcuts except the
built-in Terminal. And even then, the built-in Terminal only exposes two
actions (run script and run script over SSH). I think there's a lot that
can be done by exposing more functionality and I'm excited to see what
people do with this.

Finally, I think Shortcuts is possibly a way we can do some GUI testing
on macOS. That remains to be explored but it seems promising.

## Capability

The initial set of Shortcut actions is shown in the screenshot below:

![CleanShot 2025-06-20 at 12 19
47@2x](https://github.com/user-attachments/assets/07ac3901-8871-4ee5-a7da-663e0e2a90db)

These can be combined with the built-in shortcuts to do some pretty
interesting things.

### Future

There are more capabilities I'd like to expose, but they require
changing core parts of Ghostty that I didn't want to mix into this PR.

## Security

Scripting Ghostty can be considered a security risk, since it allows
arbitrary command execution, reading terminal output, etc. Therefore,
Ghostty will ask for permission prior to allowing any Shortcut to remote
control it:

<img width="859" alt="image"
src="https://github.com/user-attachments/assets/62344248-9c2c-402d-80f6-3fe3910d23fd"
/>

This can be directly overridden using the new `macos-shortcuts`
configuration, which defaults to `ask` but can also be set to `deny` or
`allow` with self-explanatory behaviors.
2025-06-21 07:07:10 -07:00
Mitchell Hashimoto
296f340ff4 macos: the approval dialog is now forever 2025-06-21 06:53:09 -07:00
Mitchell Hashimoto
020976bf88 macos: address some feedback 2025-06-21 06:42:32 -07:00
Mitchell Hashimoto
e4c13cdba8 macos: Optional/Array extensions need to build for iOS too 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
b6559d0899 macos: add a macos-shortcut config 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
647f29bad1 macos: intents all ask for permission 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
027171bd5d macos: can set env vars on new terminal 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
f8bc9b547c macos: support env vars for surface config, clean up surface config 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
e6c24fbf0a macos: remove confirmation option for close terminal 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
2c1e83ba2f macos: intent to open quick terminal 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
f096675eaf macos: Close Terminal Intent 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
0a27aef508 README: note Xcode 26 requirement 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
2df301e2fb macos: mouse pos and scroll intents 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
bc134016f7 macos: move mousePos and mousScroll to Ghostty.Surface 2025-06-21 06:39:20 -07:00
Mitchell Hashimoto
4445a9c637 macos: add mouse button intent 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
71b6e223af macos: input keyboard event can send modifiers and actions now 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
93619ad420 macos: Ghostty.Key 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
a6074040e7 macos: input intent 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
c904e86883 macos: invoke keybind intent 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
14e46d0979 macos: InvokeCommandPaletteIntent and CommandEntity 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
5259d0fa55 macos: starting to work on new libghostty data models 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
bbb69c8f27 macos: NewTerminalIntent returns Terminal, can split 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
683b38f62c macos: can specify parent terminal for new terminal intent 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
b8d4463754 macos: terminal not found should be an error 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
e51a93ee7c macos: Terminal entity has screen contents deferred 2025-06-21 06:39:19 -07:00
Mitchell Hashimoto
93f0ee2089 macos: GetTerminalDetails intent 2025-06-21 06:39:18 -07:00
Mitchell Hashimoto
2aa731a64e macos: TerminalEntity 2025-06-21 06:39:18 -07:00
Mitchell Hashimoto
7ae5018fe8 macos: new terminal intent 2025-06-21 06:39:18 -07:00
Mitchell Hashimoto
f55c77bc81 build: Use correct SDK for iOS Simulator shader build (#7636)
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>


![image](https://github.com/user-attachments/assets/13735334-1321-42d5-8f01-4d5f6a7660ba)
</details>

Fixes #7635.
2025-06-20 14:01:54 -07:00
Zhaofeng Li
fda08a6999 build: Use correct SDK for iOS Simulator shader build 2025-06-20 14:02:07 -06:00
Mitchell Hashimoto
d0e145292e snap: vendor libgtk4-layer-shell.so (#7623)
vendor libgtk4-layer-shell.so to ensure it's available at runtime
regardless of host system.
2025-06-18 08:38:43 -07:00
Ken VanDine
7d2da23021 snap: vendor libgtk4-layer-shell.so 2025-06-18 10:06:35 -04:00
Mitchell Hashimoto
5a788bfa90 build: use xcrun --sdk <sdk> metal for metal paths (#7619)
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.
2025-06-17 16:36:43 -07:00
Mitchell Hashimoto
30a8ba1bf6 macos: disambiguate close tab vs close window for confirmation (#7618)
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.
2025-06-17 16:24:46 -07:00
Mitchell Hashimoto
559fd92295 build: use xcrun --sdk <sdk> metal for metal paths
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.
2025-06-17 16:23:29 -07:00
Mitchell Hashimoto
51b9fa751a macos: disambiguate close tab vs close window for confirmation
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.
2025-06-17 16:16:14 -07:00
Mitchell Hashimoto
7d01332574 macOS tip regression: Confirm close on window close (#7617)
Fixes #7615

We were incorrectly closing the window without confirmation when there
were no tabs.

This was part of the undo/redo PR.
2025-06-17 15:20:53 -07:00
Mitchell Hashimoto
e6c77789d3 macOS: Confirm close on window close
Fixes #7615

We were incorrectly closing the window without confirmation when there
were no tabs.
2025-06-17 15:03:10 -07:00
Mitchell Hashimoto
676d11fd06 ci: build macOS releases with Xcode 26 (#7616)
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.
2025-06-17 14:04:57 -07:00
Mitchell Hashimoto
6d283c012e ci: build macOS releases with Xcode 26
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.
2025-06-17 13:44:13 -07:00
Mitchell Hashimoto
f794693bdc bash: remove dependency on $GHOSTTY_RESOURCES_DIR (#7611)
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.
2025-06-17 06:48:54 -07:00
Jon Parise
b629f3337a bash: remove dependency 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.
2025-06-16 19:54:27 -04:00
Mitchell Hashimoto
d0f116da35 macOS: Basic Read-Only Accessibility Integration (#7601)
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.

![CleanShot 2025-06-15 at 14 06
55@2x](https://github.com/user-attachments/assets/55eba1b4-6fd4-4d78-9434-5d672f374c67)

## After

A lot of metadata, including the screen contents as text.

![CleanShot 2025-06-15 at 14 07
25@2x](https://github.com/user-attachments/assets/e14cb7df-e4e2-4cc4-a214-004a8459f353)

Also, split hierarchies are navigable:



https://github.com/user-attachments/assets/a7b2ffb7-dbeb-41b2-8705-9c3200812c4d
2025-06-15 15:10:27 -07:00
Mitchell Hashimoto
a2b4a2c0e4 macos: complete more ax APIs for terminal accessibility 2025-06-15 14:00:39 -07:00
Mitchell Hashimoto
e69c756c89 macos: auto-expire cached screen contents 2025-06-15 13:55:06 -07:00
Mitchell Hashimoto
839d89f2dc macos: simple cache of screen contents for ax 2025-06-15 13:46:40 -07:00
Mitchell Hashimoto
e1ee180172 apprt/embedded: API to read text can get top left/bottom right coords 2025-06-15 13:06:38 -07:00
Mitchell Hashimoto
c5f921bb06 apprt/embedded: improve text reading APIs (selection, random points) 2025-06-15 07:59:19 -07:00
Mitchell Hashimoto
b46673e631 macos: Tahoe menu item icons, missed the "Ghostty" menu entirely (#7599)
This is a follow up to #7594, I missed an entire menu.
2025-06-15 07:57:11 -07:00