`WINDOWID` is the conventional environment variable for scripts that
want to know the X11 window ID of the terminal, so that it may call
tools like `xprop` or `xdotool`. We already know the window ID for
window protocol handling, so we might as well throw this in for
convenience.
Fixes#5494
When ibus/fcitx is not running (the GTK "simple" input method is
active), the preedit end event triggers _before_ the commit event. For
both ibus/fcitx, the opposite is true. We were relying on this ordering.
This commit changes the GTK input handling to not rely on this ordering.
Instead, we encode our composing state into the boolean state of whether
a key event is pressed. This happens before ANY input method events are
triggered.
Tested dead key handling on: X11/Wayland, ibus/fcitx/none.
## Description
Fixed an issue where hyperlinks would maintain their hover state when
the mouse is outside the viewport while holding the Cmd key. This
created inconsistent behavior with the window's standard hover state
clearing logic.
## Changes
- Added viewport boundary check in `mouseRefreshLinks` function to
prevent link processing when cursor is outside the window
## Testing
To reproduce and verify the fix:
1. Run `fd --hyperlink "\.zig$" src/apprt` to create hyperlinks
2. Move mouse over a hyperlink (it should highlight)
3. Move mouse outside window
4. Hold Cmd key
- Before: Link would show hover state
- After: Link remains in non-hover state
Fixes#5252
@rrotter Could you please try this to see if it solves your issue?
Requesting the initial color scheme on systems where the D-Bus interface
is nonexistent would delay Ghostty startup by 1-2 minutes. That's not
acceptable. Our color scheme events are already async-friendly anyway.
Fixes#4632
Fixes#3567
ibus 1.5.29 doesn't trigger a preedit end state when text is committed.
This is fixed in ibus 1.5.30, but we need to handle this case for older
versions which are shipped on LTS distributions such as Ubuntu.
Every other input method engine I've tried thus far also triggers a
preedit end state when text is committed, and none would expect preedit
to continue after text is committed. So I think it's safe to assume that
this is the expected behavior.
This cleans up our handling of when GTK tells us the input method
handled the key press to address more scenarios we should not encode the
key event. The comments in this diff should explain clearly.
Fixes#4332
This commit fundamentally reworks the input method handling in the GTK
apprt, making it work properly (as reported in the linked issue) on both
Wayland and X11. This was tested with both a Gnome desktop on Wayland
and i3 on X11 with fcitx and mozc.
The main changes are:
- Both key press and release events must be forwarded to the input
method.
- Input method callbacks such as preedit and commit must be expected
outside of keypress events to handle on-screen keyboards and
non-keyboard input devices.
- Input methods should always commit when told to. Previously, we would
only commit when a keypress event was given. This is incorrect. For
example, it didn't work with input method changes outside the app
which should result in committed text (as can be seen with "official"
Gnome apps like Notes or Console).
The key input handling also now generally does less so I think input
latency should be positively affected by this change. I didn't measure.
A "size-limit" function has been implemented for GTK which calls
gtk_widget_set_size_request() to set the minimum widget/window size.
Without
this function, it's left to GTK to set the minimum size which is usually
a lot larger than the documented 10x4 cell minimum size. This doesn't
fix the
issue completely as GTK retains the final say in how small a window can
be
but it gets closer.
Resolves: #4836
A "size-limit" function has been implemented for GTK which calls
gtk_widget_set_size_request() to set the minimum widget/window size. Without
this function, it's left to GTK to set the minimum size which is usually
a lot larger than the documented 10x4 cell minimum size. This doesn't fix the
issue completely as GTK retains the final say in how small a window can be
but it gets closer.
Resolves: #4836
This allows dropping files and strings onto Ghostty in the GTK apprt. If
you drop files onto Ghostty it will be pasted as a list of shell-escaped
paths separated by newlines. If you drop a string onto Ghostty it will
paste the string. Normal rules for pasting (bracketed pasts, unsafe
pastes) apply.
If the title is already the current working directory, hide the
subtitle. Otherwise show the current working directory, like if
a command is running for instance.
Signed-off-by: Tristan Partin <tristan@partin.io>
Move the toast we send when copying to the clipboard to the Surface
implementation. Previously, we only called this from the gtk accelerator
callback which we only call when the *last set* keybind is activated.
We also only send a toast if we have copied to the standard clipboard,
as opposed to the selection clipboard. By default, we have
copy-to-clipboard true for linux, which sets the selection keyboard on
any select. This becomes *very* noisy.
Commit ad503b8c4fa7 ("linux: consider Xft.dpi to scale the content")
introduced reading gtk-xft-dpi when the X11 build option is enabled.
While the name suggests it is X11-specific (perhaps it was at one
point), gtk-xft-dpi is a GTK setting that can be modified regardless of
GDK backend. GNOME’s Large Text accessibility setting ultimately
modifies it. Outside of desktop environments, it can be set via GTK
configuration files.
Remove the conditional gating the code on X11, since none of the code is
actually X11-specific. While we’re here, document scaling behaviors
under Config.font-size.
Fixes: ad503b8c4fa7 ("linux: consider Xft.dpi to scale the content")
Fixes: https://github.com/ghostty-org/ghostty/issues/4338
Link: https://docs.gtk.org/gtk4/class.Settings.html
Link: https://docs.gtk.org/gtk4/property.Settings.gtk-xft-dpi.html
