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#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.
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.
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.
To do this I forced a toolbar, so that we would have a place to put the
button when no tabs were opened. I also took the opportunity to make the
standard title/tab bar meld better with the terminal's background color,
just as we do with titlebar tabs.
Fixes#1500
This overhauls how we do focus management for surfaces to make it more
robust. This DID somehow all work before but was always brittle and was
a sketchy play with SwiftUI/AppKit behavior across macOS versions.
The new approach uses our window controller and terminal delegate
system to disseminate focus information whenever any surface changes
focus. This ensures that only ONE surface ever has focus in libghostty
because the controller ensures it is widely distributed.
