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/
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
This fixes an issue in that when running under X11, when a modifier key
is pressed, the modifier state will "lag" behind what should be current.
This is due to how X11 sends modifiers in events, i.e. it sends the
state from right before the key press, and does not include the effects
of the key press itself.
This is corrected by checking the X event queue directly for a pending
XkbStateNotify event (we mask this on modifiers), and setting the
modifiers off of that if we find one. If not, we fall back to the GDK
call.
