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.
