| Age | Commit message (Collapse) | Author |
|---|
|
- Fix `macos-dock-drop-behavior = new-tab` not working, which also
affects `open /path/to/directory -a Ghostty.app`
- Fix 'New Tab' in dock icon not working **when Ghostty's not active**
### Issue preview with `1.2.2(12187)`
https://github.com/user-attachments/assets/18068cc2-c25d-4360-97ab-cec22d5d3ff4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #8734
This forces the app icon to be set on another event loop tick from
the main startup.
In the future, we should load and set the icon completely in another
thread. It appears that all the logic we have is totally thread-safe.
|
|
Fixes #8616
macOS 26 (as of RC1) has some pathological performance bug where the
terminal becomes unusably slow after some period of time. We aren't 100%
sure what triggers the slowdown, but it is app-wide (new tabs or windows
don't resolve it) and Instruments traces point directly to
NSAutoFillHeuristicController. Specifically, to the `debounceTextUpdate`
selector.
This is all not documented as far as I can find and also not open
source, so I have no idea what's going on.
The best I can tell is that the NSAutoFillHeuristicController has
something to do with enabling heuristic-based autofill such as SMS auth
codes in text input fields. I don't know what is causing it to go
haywire.
SMS autofill is not desirable in a terminal app, nor is any of the other
automatic autofill in macOS I know of (contact info, passwords, etc.).
So, we can just disable it.
This default isn't documented but I found it via a strings dump of the
AppKit binary blob and comparing it to the disassembly to see how it is
used. In my limited testing, this seems to work around the problem.
|
|
This fixes an issue I noticed where manually launching the `ghostty`
binary in the app bundle via the CLI would open the app but not create a
window or bring it to the front.
|
|
This has no meaningful functionality yet, it was one of the paths I was
looking at for #8505 but didn't pursue further. But I still think that
this makes more sense in general for the macOS app and will likely be
more useful later.
|
|
|
|
|
|
|
|
|
|
This adds a new configuration option that controls whether folders
dropped onto the Ghostty dock icon open in a new tab (default) or
a new window.
The option accepts two values:
- tab: Opens folders in a new tab in the main window (default)
- window: Opens folders in a new window
This is useful for users who prefer window-based workflows over
tab-based workflows when opening folders via drag and drop.
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
|
|
Fixes #5256
This updates the macOS apprt to implement the `OPEN_URL` apprt action to
use the NSWorkspace APIs instead of the `open` command line utility.
As part of this, we removed the `ghostty_config_open` libghostty API and
instead introduced a new `ghostty_config_open_path` API that returns the
path to open, and then we use the `NSWorkspace` APIs to open it (same
function as the `OPEN_URL` action).
|
|
|
|
`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.
|
|
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.
|
|
Fixes #7647
See #7647 for context. This commit works by extending the `input` work
introduced in #7652 to libghostty so that the macOS can take advantage
of it. At that point, its just the macOS utilizing `input` in order to
set the command and `exit` up similar to Terminal and iTerm2.
|
|
|
|
|
|
This is a follow up to #7594, I missed an entire menu.
|
|
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).
|
|
|
|
|
|
|
|
All logic related to TerminalController is now in TerminalController.
|
|
|
|
|
|
|
|
|
|
Resolve #7526
|
|
Signed-off-by: Aaron Ruan <i@ar212.com>
|
|
I've only recently been using programs that use user notifications heavily
and this commit addresses a number of annoyances I've encountered.
1. Notifications dispatched while the source terminal surface is
focused are now only shown for a short time (3 seconds hardcoded)
and then automatically dismiss.
2. Notifications are dismissed when the target surface becomes focused
from an unfocused state. This dismissal happens immediately (no
delay).
3. Notifications are dismissed when the application exits.
4. This fixes a bug where notification callbacks were modifying view
state, but the notification center doesn't guarantee that the
callback is called on the main thread. We now ensure that
the callback is always called on the main thread.
|
|
|
|
|
|
|
|
|
|
This adds a keybinding and apprt action for #7237.
|
