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
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#4631
This introduces a mechanism by which parsed config fields can be renamed
to maintain backwards compatibility. This already has a use case --
implemented in this commit -- for `background-blur-radius` to be renamed
to `background-blur`.
The remapping is comptime-known which lets us do some comptime
validation. The remap check isn't done unless no fields match which
means for well-formed config files, there's no overhead.
For future improvements:
- We should update our config help generator to note renamed fields.
- We could offer automatic migration of config files be rewriting them.
- We can enrich the value type with more metadata to help with config
gen or other tooling.
Fixes#4631
This introduces a mechanism by which parsed config fields can be renamed
to maintain backwards compatibility. This already has a use case --
implemented in this commit -- for `background-blur-radius` to be renamed
to `background-blur`.
The remapping is comptime-known which lets us do some comptime
validation. The remap check isn't done unless no fields match which
means for well-formed config files, there's no overhead.
For future improvements:
- We should update our config help generator to note renamed fields.
- We could offer automatic migration of config files be rewriting them.
- We can enrich the value type with more metadata to help with
config gen or other tooling.
Currently `macos-titlebar-style = hidden` doesn't prevent the native
window drag gesture in the top region of the window- in the original PR
it did, but there were issues with how it went about it so it was
removed (see c6bbdfb). I figured out how to safely and simply remove the
gesture, and as a bonus it opens up potential future enhancements.
The native window drag region is driven ultimately by the window's
`contentLayoutRect`, so we can just override it in `TerminalWindow` to
return a rect the size of the full window, disabling the gesture without
causing any side effects by altering the responder chain.
This makes `macos-titlebar-style = hidden` a much nicer experience. The
window can still be resized, managed by the OS and third party window
managers, and dragged by the edges, but the native drag gesture in the
titlebar region is fully avoided.
### Future work
We may consider adjusting this to produce a `contentLayoutRect` that
doesn't include the padding area of the terminal grid(s), so that the
window can be dragged from a larger region around the edges (and not
just the resize region).
The native window drag region is driven ultimately by the window's
`contentLayoutRect`, so we can just override it in `TerminalWindow`
to return a rect the size of the full window, disabling the gesture
without causing any side effects by altering the responder chain.
NEEDS REVIEW
continuation of #5037resolves#4729
renders all shaders to the default buffer and then copies it to the
designated custom shader texture.
this is a draft pr because:
- it introduces a new shader "pipeline" which doesnt fit in with how the
system was designed to work (which is only rendering to the fbo)
- im not sure if this is the best way to achieve shaders being able to
sample their output while also drawing to the screen. the cusom fbo
(previous implementation) was useful in that it modularized the custom
shader stage in rendering
---------
Co-authored-by: Mitchell Hashimoto <m@mitchellh.com>
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.
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.
A '-' or '--' argument signals the end of bash's own options. All
remaining arguments are treated as filenames and arguments. We shouldn't
perform any additional argument processing once we see this signal.
We could also assume a non-interactive shell session in this case unless
the '-i' (interactive) shell option has been explicitly specified, but
let's wait on that until we know that doing so would solve a real user
problem (and avoid any false negatives).
Related to #3567
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.
Reproduction is simple:
1. Use ibus (X11 or Wayland doesn't matter)
2. Press `super+.` to activate the emoji keyboard
3. Notice the `.` is written to the shell AND the emoji keyboard is
activated.
The bug is that `.` should not be encoded since it was used to activate
the emoji keyboard. This PR fixes that.
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
