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.
We were previously retaining Options on the Surface struct, but other
than userdata, we only use those values for initialization. Instead,
store just the opaque userdata value on the Surface and clarify that
Surface.Options are only used for initialization.
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
Normally, when `ctrl+<character>` is pressed, such as `ctrl+z` or
`ctrl+c`, macOS (AppKit) doesn't do any key translation because that
doesn't map to any printable text on its own. Ghostty does the
translation to correctly determine the character is "z" or "c" or
whatever.
For some reason when the keyboard layout is "Dvorak - QWERTY Cmd"
specifically (_not_ plain "Dvorak") on a US layout keyboard, AppKit
decides that "ctrl+z" ("/" on a qwerty keyboard) translates to "/"...
I can't find any explanation for this.
To workaround this, this commit makes it so that if the following
conditions are true, then we IGNORE AppKit's text translation and
manually do it using UCKeyTranslate:
(1) We're on macOS specifically (not iOS, etc.)
(2) We have a key event with ONLY control pressed
This fixes `ctrl+z` on this unique Dvorak keyboard layout.
Previously, we encoded `ctrl+_` in the CSIu format[1]. This breaks most
notably emacs which expects the legacy ambiguous encoding.
This commit utilizes the generator from Kitty to generate our control
key mappings. We also switch from keycode mapping to key contents
mapping which appears to be the correct behavior also compared to other
terminals.
In the course of doing this, I also found one bug with our fixterms
implementation. Fixterms states: "The Shift key should not be considered
as a modifier for Unicode characters, because it is most likely used to
obtain the character in the first place (e.g. the shift key is often
required to obtain the ! symbol)." We were not applying that logic and
now do.
[1]: https://www.leonerd.org.uk/hacks/fixterms/
