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 gets `zig build -Dtarget=aarch64-ios` working. By "working" I mean
it produces an object file without compiler errors. However, the object
file certainly isn't useful since it uses a number of features that will
not work in the iOS sandbox.
This is just an experiment more than anything to see how hard it would be to
get libghostty working within iOS to render a terminal. Note iOS doesn't
support ptys so this wouldn't be a true on-device terminal. The
challenge right now is to just get a terminal rendering (not usable).
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).
A lot of the state that we put on Exec is just there to copy to
StreamHandler, but we already have it in DerivedConfig. I think this
whole copy copy copy is just legacy cruft since termio.Exec is one of
the older parts of the source code.
This rearchitects the Exec struct to act more like Surface and Renderer
where it stores its derived config. This lets us avoid a few extra
allocations and removes a LOT of struct member noise from termio.Exec.
For pointer lifetimes, the memory allocated is now owned by
DerivedConfig. When changeConfig is called, its the only time BOTH are
still alive, so we can safely swap pointers and deinit without having to
duplicate across threads. This is the same as renderer/surface.
Fixes#1214
This introduces the `window-colorspace` configuration which allows
configuring the colorspace to use for windows on macOS. The default is
sRGB (same as before) but this can also be set to `display-p3`.
Fixes#1099
We previously applied application keypad mode logic (`ESC=` or mode 66)
whenever it was active. However, from looking at the behavior of other
terminals (xterm and foot) it appears this isn't correct.
For xterm, application keypad mode only applies unconditionally if the
keyboard mode is VT220 (`-kt vt220`). For modern terminals, application
keypad mode is only applied if mode 1035 is disabled.
Mode 1035 is the "ignore numpad state with keypad mode" mode. It
defaults to true on terminal startup. If this is true, keypads are
always encoded in numerical mode. If this is false, the numlock state
will be respected.
Associated text should only be reported when it was generated from the
key event. To my knowledge, there are no release events which produce
text. This now matches kitty reporting for release events.