Fixes#734
I don't know much about SwiftUI, but here's why I think this works.
- Moving the `inspectorVisible` logic to an `onChange` ensures the view
has at least seen that change.
- The dispatch to the main thread is still necessary to ensure the view
hierarchy has completely updated after `inspectorVisible`.
Note that this fix is to correctly regain focus. We still lose window
focus very briefly.
Fixes#1833
This is an attempt to simplify the logic that has organically grown
convoluted over time with regards to how the titlebar and tab bar is
styled.
This field is one unified field that ONLY addresses titlebar and tab bar
styling. It can be one of "native", "transparent", or "tabs". The
"native" field is the new behavior in this commit: it makes the titlebar
and tab bar appearance be absolutely native. We do not color anything
(if we do its a bug).
The "transparent" option is the previous `macos-titlebar-tabs = false`
setting where the titlebar/tab bar is native but colored according to
the window background color.
The "tabs" option is `macos-titlebar-tabs = true`.
The `window-theme = auto` affect on titlebar appearance has been
removed. Now, the titlebar will NEVER be styled with "native" and MAY be
styled with "transparent" and will ALWAYS be styled with "tabs" (since
that's a totally custom look anyways).
Fixes#1802
This allows `keybind` configurations to map to any Unicode codepoint. This enables keybindings for which we don't have a registered keycode or for custom keyboard firmwares that may produce arbitrary text (but the Ghostty support is limited to a single codepoint).
The `keybind` syntax is unchanged. If a bound character doesn't map to a known logical key that Ghostty knows about, we map it to a Unicode codepoint. The unicode codepoint is compared against the _unshifted codepoint_ from the apprt key event.
Note that this binding is to a single _codepoint_. We don't support arbitrary sequences of characters or multi-code point graphemes for keybindings due to the complexity in memory management that would introduce.
This also provides a good fallback for scenarios where it might make sense to educate Ghostty about a key code or fix a bug in our keyboard input system, but the unicode data is correct. In that scenario, unicode key binds should allow key binds to still work while we investigate the input issues.
Example:
```
shift+ö=text:hello
```
This now works as expected on a US hardware keyboard with the Hungarian keyboard layout.
Fixes#1771
I'm not convinced this fix won't regress some other behavior, but in my
titlebar tab and native tab modes with and without transparency, this
has looked okay to me.
Fixes#1756
We previously converted from view to screen coordinates but if the view
doesn't take up the full window then the view coordinates are wrong. We
need to convert to window coordinates in the middle.
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.
We allow titlebarFont to be nil to differentiate between "system" (nil)
and "custom" (non-nil) behavior. For the "system" case, we need to use
the system _titlebar_ font (rather than just the default system font),
to match the system's conventions.
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
```
Add support for configurable fonts for window and tab titles. This is
only implemented for macOS (and could be macOS-only if other platforms
aren't able to support this using their windowing toolkits). It plays
nicely with regular and titlebar tabs.
