Fixes https://github.com/ghostty-org/ghostty/issues/4947 for gtk
This PR implements the senstive content hiding when displaying the paste
confirmation dialog in secure input mode.
Following changes are implemented:
- in the blueprint for each dialog add a show/hide button that is not
visible by default, and a Revealer that is revealed by default
- save the `secure_input` action value for each surface in the GTK apprt
- pass the value when initializing the paste confirmation dialog
- in the dialog code, alter the visibility of the content and
reveal/hide buttons based on secure input flag value
Demo:
https://github.com/user-attachments/assets/c91cbd3d-ed3b-464d-b4cf-e51fe7aa23b7
I feel like this is already a nearly full implementation, but I'm
leaving this as a draft for now, since i need to look into blueprints
for Adwaita 1.2, and verify if it behaves properly when the dialog is in
not-sensitive input mode and in OSC52 mode.
This is my third (!) attempt at implementing localization support. By
leveraging GTK builder to do most of the `gettext` calls, I can avoid
the whole mess about missing symbols on non-glibc platforms.
Added some documentation too for contributors and translators, just for
good measure.
Supersedes #5214, resolves the GTK half of #2357
Remove the flag which reports all scrolls as discrete scrolls. This
enables precision scrolling in GTK. We have to track a flag between
continuous scroll events.
As noted in the comments, this is so that apprt's can always know what
the default size of a window would be so they can utilize this for
"return to default size" actions.
The initial size shouldn't be treated as a "resize" event and was
already documented as such. Prior to this commit the docs already noted
that the initial size may be sent multiple times but only the first time
during initialization should be used as a resize.
Therefore, this shouldn't impact prior behavior. I've verified this with
the apprts.
Note that for Debian 12, the blueprints must be compiled on a distro
with a newer version of `blueprint-compiler` and the raw UI XML
committed to git. Debian 12 includes `blueprint-compiler` 0.6.0 which
doesn't support compiling `adw.MessageDialog` even though the version of
`libadwaita` supports it.
Fixes#5927
This doesn't fix the underlying reason that GTK sometimes reports
content scales as negative. If GTK reports a negative scale, we ignore
that and use 1.0 for the scale.
This will be needed to the convert GTK apprt surfaces to a DerivedConfig
model rather than accessing the global config stored in the app. It's a
no-op for now, but I have a PR in the works to update the resize overlay
that will take advantage of this.
`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.
