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.
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.
Resolves#4523
More notably this fixes a memory corruption crash that can occur while
resizing the font under Metal while there's a lot of active changes
occurring (e.g. while running DOOM fire). The change where all
background colors are explicitly written exposed this issue, though it
was technically a problem the whole time I'm fairly sure, just that the
corruption it caused before was benign.
This significantly improves the robustness of the renderers since it
prevents synchronization issues from causing memory corruption due to
out of bounds read/writes while building the cells.
TODO: when viewport is narrower than renderer grid size, fill blank
margin with bg color- currently appears as black, this only affects
DECCOLM right now, and possibly could create single-frame artefacts
during poorly managed resizes, but it's not ideal regardless.
This significantly improves the robustness of the renderers since it
prevents synchronization issues from causing memory corruption due to
out of bounds read/writes while building the cells.
TODO: when viewport is narrower than renderer grid size, fill blank
margin with bg color- currently appears as black, this only affects
DECCOLM right now, and possibly could create single-frame artefacts
during poorly managed resizes, but it's not ideal regardless.
#4033 introduced a `ctrl-shift-w` binding to close a tab, but it doesn't
respect the `confirm-close-surface` option. Now `ctrl-shift-w` will ask
for confirmation exactly the same as clicking the close button with the
mouse.
fixes#4729
allows the shaders to sample each other via the fbo texture.
also, a better example would use the full screen e.g.:
"behind.glsl"
```glsl
void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
fragColor = vec4(fragCoord/iResolution.xy, 0.0, 1.0);
}
```
"infront.glsl"
```glsl
void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
fragColor = texture(iChannel0, fragCoord/iResolution.xy);
}
```
`ghostty --custom-shader=behind.glsl --custom-shader=infront.glsl`
|before|after|
|-|-|
|
|
|
Fixes core issue #4957. Adds a bool to `SelectLine` allowing the
`selectLine` function to select lines that are empty. When starting a
triple selection on an empty line the initial `selectLine` returns null
because we don't see any characters, in this case we rerun `selectLine`
but short circuit with the `allow_empty_lines`. We need to run
`selectLine` with out allowing empty lines once because if there are
characters on the line we don't want to select empty space.
Resolves#5108
Reproduction: While Stage Manager is activated, create a new tab in
Ghostty, run `sleep 500` in that tab, and try and close it. Make sure to
try both closing the tab with cmd-w and clicking the x; also try
accepting the modal with a mouse click and pressing enter.
Relevant AppKit documentation: [NSAlert
beginSheetModal](https://developer.apple.com/documentation/appkit/nsalert/beginsheetmodal(for:completionhandler:))
What I believe is happening is that the alert modal ("there is still a
process running") is closed automatically after the completion handler
is run, which closes the window on which the alert is attached.
Something seems to go wrong in Stage Manager at this point; perhaps it
detects the alert closing as a "full" window closing and moves focus to
a different window.
The fix I've identified is to manually call the `orderOut` function to
dismiss the alert _before_ the code that closes the window is run.
## Descriptions
The code was short-circuiting the shell integration setup when
`shell-integration = none`, which prevented the feature environment
variables from being set. These environment variables are needed even
for manual shell integration to work properly.
## Changes
- Extracted feature environment variables setup into a separate
`setup_features` function
- Modified the shell integration initialization to ensure features are
set up even when `shell-integration = none`
<img width="1126" alt="image"
src="https://github.com/user-attachments/assets/ceeb33f5-26ee-4a3b-a6d5-eed57848c96c"
/>
Fixes https://github.com/ghostty-org/ghostty/issues/5046
The variant format string `^aay` is said to be equivalent to
`g_variant_new_bytestring_array`. Given that no length parameter is
provided, glib assumed a null-terminated array, causing a crash as glib
exceed the read boundaries to copy arbitrary memory.
This commit replaces the array construction code to use its arena
equivalents instead of glib, and make sure that the resulting array is
null-terminated.
Fixes#3616.
This was causing excessively faint/dark areas anywhere there was
transparency, since our image shaders for both Metal and OpenGL assume
the image data has straight alpha (which, I think should be the case for
data transmitted directly with kitty graphics protocol rather than
png-encoded), and do an additional multiplication.
After this change, our image blending looks *like most other apps*, even
though it's still technically wrong since it "should" be done in linear
space. Kitty, for example, does do linear blending for images, which is
*more correct* even though it doesn't look like most apps. On macOS if
`text-blending` is set to `linear` we do get linear blending, and match
Kitty exactly with this change.
In order to have linear blending of images while maintaining non-linear
blending of text for a "native" look on macOS we'd have to use swap
textures with different pixel formats (`*_srgb` / not `*_srgb`) or else
the API validator yells at us (even though it *does* work correctly...)
-- either that or perform our blending in a shader instead of relying on
Metal, which is my plan ultimately whenever I get around to making the
deferred render pipeline.
login(1)'s .hushlogin logic was "fixed" in macOS Sonoma 14.4, so this
comment (and our workaround) is only relevant for versions earlier than
that.
The relevant change to login/login.c is part of system_cmds-979.100.8.
> login.c: look for .hushlogin in home directory (112854361)
-
1bca46ecc5
-
https://github.com/apple-oss-distributions/distribution-macOS/tree/macos-144
The intention of #5075 was to create a less intrusive, more hermetic
environment in which to source the bash startup files. This caused
problems for multiple people, and I believe that's because the general
expectation is that these files are sourced at global (not function)
scope.
For example, when a file is sourced from within a function scope, any
variables that weren't explicitly exported into the global environment
won't be available outside of the scope of the function. Most system and
personal startup files aren't written with that constraint because it's
not how bash itself loads these files.
As a small improvement over the original code, `rcfile` has been renamed
to `__ghostty_rcfile`. Avoiding leaking this variable while sourcing
these files was a goal of #5075, and prefixing it make it much less of a
potential issue.
This change also reverts the $HOME -> ~/ change. While the ~/ notation
is more concise, using $HOME is more common and easier to implement
safely with regard to quoting.
Fixes#5206
The intention of #5075 was to create a less intrusive, more hermetic
environment in which to source the bash startup files. This caused
problems for multiple people, and I believe that's because the general
expectation is that these files are sourced at global (not function)
scope.
For example, when a file is sourced from within a function scope, any
variables that weren't explicitly exported into the global environment
won't be available outside of the scope of the function. Most system and
personal startup files aren't written with that constraint because it's
not how bash itself loads these files.
As a small improvement over the original code, `rcfile` has been renamed
to `__ghostty_rcfile`. Avoiding leaking this variable while sourcing
these files was a goal of #5075, and prefixing it make it much less of a
potential issue.
This change also reverts the $HOME to ~/ change. While the ~/ notation
is more concise, using $HOME is more common and easier to implement
safely with regard to quoting.
ghostty#5000 changed the window level from `.popupMenu` to `.floating`
to improve IME support. However, this introduced a side effect which
render the Quick Terminal (QT) below the macOS menu bar, whereas
previously it would cover it.
When positioned on `right` and `left`, the top of the QT becomes
partially hidden. This PR adjust the size of the QT to ensure it remains
fully visible and stays below the menu bar.
login(1)'s .hushlogin logic was "fixed" in macOS Sonoma 14.4, so this
comment (and our workaround) is only relevant for versions earlier than
that.
The relevant change to login/login.c is part of system_cmds-979.100.8.
> login.c: look for .hushlogin in home directory (112854361)
- 1bca46ecc5
- https://github.com/apple-oss-distributions/distribution-macOS/tree/macos-144
The variant format string `^aay` is said to be equivalent to
g_variant_new_bytestring_array. Given that no length parameter is
provided, g_variant_new assumed a null-terminated array, but the array
constructed by the code was not, causing a crash as glib exceed the read
boundaries to copy arbitrary memory.
This commit replaces the array construction code to use its arena
equivalents instead of trying to build one using glib, and make sure
that the resulting array is null-terminated.
It seems like the raw data version of the kitty graphics transmit
operation is meant to be unassociated (aka straight) alpha, though I
can't find any definitive documentation either way- but in any case
unassociated alpha is more common in image formats and makes the
handling easier for the rest of it.
Also removed a redundant call to `decode_frame_config`, since it's
called implicitly when we call `decode_frame` right after.
`load_color` was multiplying the alpha channel by itself as well, rather
than just the `rgb` channels.
Also made sure to divide alpha out before applying gamma encoding back
to text color when not using linear blending, which was another source
of error.
Probably fixes the problem observed in #5133 -- I couldn't reproduce the
exact color shift, but did see a similar one with some of my test
colors. This most visibly affects dimmed text since it uses an alpha of
less than 1 for the text color.
Allowing the alert to be automatically closed after the completion handler finishes doesn't seem to play well when the completion handler closes the window on which the alert is attached
We use `trap` to bootstrap our installation function (__bp_install). We
remove our code upon first execution but need to restore any preexisting
trap calls. We previously used `sed` to process the trap string, but
that had two downsides:
1. `sed` is an external command dependency. It needs to exist on the
system, and we need to invoke it in a subshell (which has some runtime
cost).
2. The regular expression pattern was imperfect and didn't handle
trickier cases like `'` characters in the trap string:
$ (trap "echo 'hello'" DEBUG; trap -p DEBUG)
hello
trap -- 'echo '\''hello'\''' DEBUG
This change removes the dependency on `sed` by locally evaluating the
trap string and extracting any prior trap. This works reliably because
we control the format our trap string, which looks like this (with
newlines expanded):
__bp_trap_string="$(trap -p DEBUG)"
trap - DEBUG
__bp_install
Upstream: https://github.com/rcaloras/bash-preexec/pull/170
