This was recently introduced a few days ago. Unfortunately, this doesn't
work as expected. The "function" modifier is not actually the fn key
but used by macOS to represent a variety of "functional" key presses.
This breaks other bindings such as #2411.
I can't find a source on the internet that reliably tells me how we
can detect fn key presses, but I do find a number of sources that tell
us we can't.
This also slightly changes the code, as the duplication of the for loop
was making it harder to read now. I think technically slightly less
efficient, but this is hardly a hot code path, so should be fine imo.
First, this commit modifies libghostty to use a single unified action
dispatch system based on a tagged union versus the one-off callback
system that was previously in place. This change simplifies the code on
both the core and consumer sides of the library. Importantly, as we
introduce new actions, we can now maintain ABI compatibility so long as
our union size does not change (something I don't promise yet).
Second, this moves a lot more of the functions call on a surface into
the action system. This affects all apprts and continues the previous
work of introducing a more unified API for optional surface features.
I make the following suggestion through a PR since I already tried this locally and have a branch ready:
- Rename Split Horizontally to Split Right
- Rename Split Vertically to Split Down
Rationale:
The terms horizontal and vertical are ambiguous in the context of splitting (does it mean the splitter is vertical, or are the panes organized vertically?)
Different apps pick different interpretations, so people get confused.
IntelliJ made the same change as above based on user feedback: https://youtrack.jetbrains.com/issue/IJPL-130991/Split-Vertically-and-Split-Horizontally-are-ambiguous-and-should-be-renamed
Ghostty is using the left/right nomenclature in other menu items. In the codebase, SplitDirection is already left/right.
Fixes#1656
When called as part of window restoration AppKit has a lock, so
NSAppearance changes need to be called async.
See deadlock:
```
Thread 1 Queue : com.apple.main-thread (serial)
0 0x000000018fd63fac in __ulock_wait ()
1 0x00000001069bf720 in _dlock_wait ()
2 0x00000001069bfaec in _dispatch_group_wait_slow ()
3 0x0000000106b5f5c4 in interposed_dispatch_group_wait ()
4 0x00000001937fb1f0 in NSCGSTransactionRunPreCommitActions_ ()
5 0x00000001938f1230 in -[_NSCGSTransaction synchronize] ()
6 0x00000001938f11ac in NSCGSTransactionSynchronize ()
7 0x000000019382ad30 in +[NSCGSWindow(NSCGSSpace) isAnyWindowOnAVisibleSpace:] ()
8 0x000000019382a968 in -[NSWindow _isInSomeVisibleSpace] ()
9 0x000000019382a8e4 in -[NSWindow isOnActiveSpace] ()
10 0x0000000193db8d98 in -[NSApplication(NSApplicationAppearance_Internal) _invalidateWindowAppearances] ()
11 0x00000001938f44d4 in -[NSApplication(NSAppearanceCustomization) setAppearance:] ()
12 0x0000000102c48050 in AppDelegate.syncAppearance() at /Users/mitchellh/code/go/src/github.com/mitchellh/ghostty/macos/Sources/App/macOS/AppDelegate.swift:412
13 0x0000000102c47840 in AppDelegate.configDidReload(_:) at /Users/mitchellh/code/go/src/github.com/mitchellh/ghostty/macos/Sources/App/macOS/AppDelegate.swift:380
14 0x0000000102c43c7c in AppDelegate.applicationDidFinishLaunching(_:) at /Users/mitchellh/code/go/src/github.com/mitchellh/ghostty/macos/Sources/App/macOS/AppDelegate.swift:110
```
It uses a private compositing filter to match what the sytem does to
color unselected tabs in the window's tab bar (specifically with a
light appearance).
Fixes#1389
This is just a fun AppKit quirk. This menu item is set automatically
based on the keyboard shortcut (apparently) and when its overwritten
then its gone forever. So, let's just not set it.
