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#1606
This improves our logging when this occurs and prevents a crash.
The program will just run indefinitely with no windows (you can try to
create another but it will probably fail) but the logs are much more
helpful now.
Use glib-compile-resources to compile CSS style sheets and icons into
the Ghostty GTK binary. Makes for simpler access to icons and sets
things up for customizing the look of Ghostty with CSS in the future.
The CSS style sheets are blank for now so there will be no visual
changes.
On my system (xorg Ubuntu 24.04, Adwaita:dark theme) tab close icon was
red while in all other applications was more discrete. With adding
`-symbolic` to the icon name now looks like all other application.
When gtkInputPreeditChanged is called after gtkInputCommit, character
that should be committed is cleared. Check if there's buffered character
and send the characters directly when preedit changed.
Fix#1563
This was reported on Discord. A Chromebook reported an `Xft.dpi` of
`96.1025390625` which resulted in a `gtk-xft-dpi` of 98409. This caused
`divExact` to crash in runtime safety modes.
This adds a new config option: `window-append-new-tabs` (please: if you
have a better name, let me know). If this is set to true, then new GTK
tabs aren't added after the current tab, but after at the end.
On X11 gdk_device_get_modifier_state does not correctly return the
modifier state, while the modifier state passed to the key callback
does. On Wayland, the situation is exactly reversed.
Therefore on X11 we use the mods provided by the key callback and on
Wayland we continue to get the modifier state from the device.
`App.modifier_state_from_xkb` is removed since we can lift the
conditional out of the function call (we would need to make a second,
redundant check for the presence of `x11_xkb` otherwise).
Many applications use Xft.dpi to scale their contents (e.g. Chromium,
kitty, alacritty...). This value also gets set by DE setting managers
and can be manually set in ~/.Xresources if using, e.g., i3.
This should make HiDPI on Linux more consistent even when not using
GTK-specific methods (e.g. GDK_SCALE=2).
Note that we still consider GTK scaling, so it's possible to use the two
independently.
Closes#1243
