There's one behavioral change here. Before this patch, if
`gtk-titlebar=false` we _never_ created a headerbar. This explicitly
contradicted the comments in the source, and the documentation for
`gtk-titlebar` imply that if a window starts out without a titlebar it
can be brought back later with the `toggle_window_decorations` keybind
action.
After this patch, a headerbar is always created, but if
`gtk-titlebar=false` or `window-decoration=false` it's immediately
hidden.
I'm not sure how this interacts with the current SSD/CSD detection that
seems to happen when running Ghostty on non-Gnome DEs so it'll be
important to get #4724 merged (plus any follow ups) to enable more
explicit control of SSD/CSD.
This is a hack to make it easier for our GitHub branching rules to
require a single check to pass before merging. This lets us describe the
required checks in code rather than via the GH UI.
This is a hack to make it easier for our GitHub branching rules to
require a single check to pass before merging. This lets us describe the
required checks in code rather than via the GH UI.
This PR addresses https://github.com/ghostty-org/ghostty/issues/4732.
While @tristan957 suggested alternative approaches, this implementation
provides a straightforward way to make the menu accessible when the
window decoration is disabled. It follows patterns seen in other GTK
apps for handling submenus, though not strictly in the context menu
format truth be told.
If there’s a better way to approach this or further refinements needed,
I’m happy to discuss and iterate. This has been a minor issue I’ve
encountered personally, and I’d like to help improve the experience for
others as well.
Small video of how it looks:
https://github.com/user-attachments/assets/59548fef-f11c-421f-b05b-be81eab6ce06
Fixes:
https://github.com/ghostty-org/ghostty/issues/4634#issuecomment-2573469532
This commit fixes two issues:
1. `libghostty` must not override ctrl+key inputs if we are in a preedit
state. This allows thigs like `ctrl+h` to work properly in an IME.
2. On macOS, when an IME commits text, we strip the control modifier
from the key event we send to libghostty. This is a bit of a hack but
this avoids triggering special ctrl+key handling.
Fixes: https://github.com/ghostty-org/ghostty/issues/4634#issuecomment-2573469532
This commit fixes two issues:
1. `libghostty` must not override ctrl+key inputs if we are in a preedit
state. This allows thigs like `ctrl+h` to work properly in an IME.
2. On macOS, when an IME commits text, we strip the control modifier
from the key event we send to libghostty. This is a bit of a hack but
this avoids triggering special ctrl+key handling.
Fixes#4801
Our size calculation before improperly used a screens frame instead of
its visibleFrame. Additionally, we didn't properly account for origin
needing to move in order to fit the window on the screen.
Apparently, setting a frame height to high crashes AppKit. The width
gets clamped by AppKit but the height does not. Fun!
Fixes#4801
Our size calculation before improperly used a screens frame instead of
its visibleFrame. Additionally, we didn't properly account for origin
needing to move in order to fit the window on the screen.
Apparently, setting a frame height to high crashes AppKit. The width
gets clamped by AppKit but the height does not. Fun!
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
## Description
This PR implements the `copy_url_to_clipboard` keybind action. This
action allows users to copy URLs directly to the clipboard without
needing to select them first.
### Features
- Works with both regex-matched URLs and OSC8 hyperlinks
- Copies only the URL portion, not the surrounding text
- Respects the `clipboard_trim_trailing_spaces` configuration
- Provides clear error feedback
- Follows the same patterns as other clipboard operations
https://github.com/user-attachments/assets/c9c82e3d-dfc5-4171-b367-d6799305d87f
Resolves https://github.com/ghostty-org/ghostty/issues/4633
This produces the following keybind, which I believe was intended.
> keybind = cmd+backspace=text:\x15
Matches the cmd+left and cmd+right which are a few lines up.
#3679#3646
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.
read(2) returning 0 means that the other end of the pipe/pty has been
closed (EOF), so there cannot be any more output to read on the pipe,
and
the io reader thread can just exit.
If exec.wait_after_command=false, the read thread's quit pipe is
immediately written to after the child process dies, so all is well.
However, if wait_after_command=true (which is the case when using
Ghostty
to run a .command/.sh file on macOS), the read thread keeps spinning,
causing persistent 100% CPU usage per exited process.
Fix it by exiting the reader thread on EOF.
If the read thread has already exited, it will have closed the read end
of the quit pipe. Unless SIGPIPE is masked with signal(SIGPIPE, SIG_IGN),
or the macOS-specific fcntl(F_SETNOSIGPIPE), writing to the write end of
a broken pipe kills the writer with SIGPIPE instead of returning -EPIPE
as an error. This causes a crash if the read thread exits before
threadExit.
This was already a possible race condition if read() returns
error.NotOpenForReading or error.InputOutput, but it's now much easier to
trigger due to the recent "termio/exec: fix 100% CPU usage after
wait-after-command process exits" fix.
Fix this by closing the quit pipe instead of writing to it.
