As of version 1.0.1 (macOS build) when running the toggle visibility
action a window with tabs is made into multiple windows.
This PR ensures terminal tabs are reconstructed and correctly placed
into its parent window.
# Demo
https://github.com/user-attachments/assets/44f14bca-15a1-4717-ba0a-44f0767feec3
FYI: I will create another PR to ensure the right tab is focused after
the main window is restored.
Solves #4329
Two major changes:
1. Hiding uses `NSApp.hide` which hides all windows, preserves tabs, and
yields focus to the next app.
2. Unhiding manually tracks and brings forward only the windows we hid.
Proper focus should be retained.
Fixes#4799
This PR attempts to reduce the flash caused by the ghost emoji in the
title bar when opening new windows.
## Changes:
- Initialize `SurfaceView.title` with empty string instead of ghost
emoji
- Simplify title computation logic in `TerminalView`
- Adding a 500ms fallback timer for "👻"
- Canceling timer if title is set
## Current Status:
While these changes reduce the initial ghost emoji flash, there's still
a brief moment where a folder emoji appears alone in the title bar when
opening a new window. This suggests there might be a race condition or
timing issue with how the title is being set and updated.
https://github.com/user-attachments/assets/3688c9f3-1727-4379-b04d-0bd6ac105728
Would appreciate feedback on the remaining flash issue and suggestions
for further improvements.
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
