This patch fixes#2010 by implementing `quit-after-last-window-closed`
for the GTK apprt. It also adds the ability for the GTK apprt to exit
after a delay once all surfaces have been closed and adds the ability to
start Ghostty without opening an initial window.
This is a CLI-only config. This is the first such config. I am only
pointing this out since it is a new pattern for Ghostty.
By specifying `--config-default-files=false`, Ghostty will discard any
configuration set in the default files it loads. This makes running
Ghostty from the CLI easier if you want to "reset" the configuration to
the "factory defaults."
When set, the cursor-invert-fg-bg option uses the inverted foreground
and background colors of the cursor's current cell to color the cursor,
rather than using a fixed color. This option has higher precedence than
the cursor-color and cursor-text options, but has lower precedence than
an OSC 12 command to change the cursor color.
This is a quality of life UX change. font-family is a repeatable
configuration where each subsequent value will be added as a fallback
font.
This introduces a UX gotcha where if a font was set in a config file,
the CLI args (which are loaded later) would _append_ to the font
families. This has never once been the behavior I've wanted. Previously,
you'd have to do `--font-family=""` which is clunky.
This change makes it so that CLI font-family flags will automatically
clear the families set in the configuration file.
`gtk-single-instance` should already be doing desktop-only detection and
in most cases it does. But there are some cases where it isn't and we
haven't quite tracked it down yet.
In any case, when `-e` is used from the CLI, we definitely do not want
to launch in single instance mode because `-e` is typically used in
scripts or for one-off instances. This forces gtk-single-instance to
false.
For a long time, us GTK users have been subject to lesser UX by not
knowing which split was focused. Improve the GTK UX by implementing both
unfocused-split-opacity and unfocused-split-fill. This is implemented by
setting the background-color of the notebook stack, and conditionally
applying a new css class "unfocused-split" to the unfocused split.
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#1724
See background in #1724. The general idea is that for Ghostty
invocations via xdg-terminal-exec, we set the initial title to the
command automatically so that window managers can modify the styling.
We only do this for xdg-terminal-exec because that protocol/spec is
specifically for the scenario that the terminal is being used to launch
a command from the desktop environment.
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.
