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!
Adds the missing Bluetooth permission to Ghostty's application playlist
manifest file, as it was missing. Tweaks have also been made to existing
permission descriptions to be more readable. Should fix an abrupt crash
in Fastfetch and any other apps that may request Bluetooth permissions.
Adds the missing Bluetooth permission description to ghostty's Xcode
project description, and fixes up existing permissions to be clearer.
Closes#3995 and #4512.
Fixes#4539
AquaSKK is a Japanese IME (Input Method Editor) for macOS. It uses
keyboard inputs to switch between input modes. I don't know any other
IMEs that do this, but it's possible that there are others. Prior to
this change, the keyboard inputs to switch between input modes were
being sent to the terminal, resulting in erroneous characters being
written.
This change adds a check during keyDown events to see if the input
source changed _during the event_. If it did, we assume an IME captured
it and we don't pass the event to the terminal.
This makes AquaSKK functional in Ghostty.
This changes quit signaling from a boolean return from core app `tick()`
to an apprt action. This simplifies the API and conceptually makes more
sense to me now.
This wasn't done just for that; this change was also needed so that
macOS can quit cleanly while fixing #4540 since we may no longer trigger
menu items. I wanted to split this out into a separate commit/PR because
it adds complexity making the diff harder to read.
After updating to 1.0.1 I noticed something different in the terminal,
which turned out being the window borders - it appeared as if Ghostty
was using light-mode style borders (dark/black outline with a thin light
stroke at the top) instead of the entire light outline from before:
| 1.0.0 | 1.0.1 |
| - | - |
| <img width="308" alt="Screenshot 2025-01-01 at 2 28 12 PM"
src="https://github.com/user-attachments/assets/d8bc5bdd-c3b2-401c-a8ed-9da0b768cb3d"
/> | <img width="308" alt="Screenshot 2025-01-01 at 2 29 07 PM"
src="https://github.com/user-attachments/assets/fd710bed-1756-4f66-8402-bfbdd25218ab"
/> |
After digging a bit, I found #3834, which fixes fullscreen background
colors through alpha channels by appending a `withAlphaComponent(0.0)`
to `backgroundColor` - for reasons I may be entirely unaware of (since
I'm not a Swift developer), this seems to cause the dark-mode border
style to go away.
Some lines above that, I noticed the `.clear` callout from line 266,
which talks about matching Terminal.app's styles, and it _also_ has a
`withAlphaComponent` but set to `0.001` - if I understand correctly, and
the fix from #3834 works by setting the alpha component to a
_practically_ zero value, then I thought perhaps a really small number
like `0.001` could do the trick as well. This ended up working and
bringing back the right borders again.
Not sure again if this may make a difference anywhere else in the app or
bring any undesired behavior, but if anyone who is well-versed in Swift
would like chime in with more details or perhaps a better approach, I'd
greatly appreciate it!
When unset, we use Sparkle's default behavior, which is based on the
user's preference stored in the standard user defaults.
The rest of the previous behavior is preserved:
- When SUEnableAutomaticChecks is explicitly false, auto-updates are
disabled.
- When 'auto-update' is set, use its value to set Sparkle's auto-update
behavior.
Fixes#4433
When unset, we use Sparkle's default behavior, which is based on the
user's preference stored in the standard user defaults.
The rest of the previous behavior is preserved:
- When SUEnableAutomaticChecks is explicitly false, auto-updates are
disabled.
- When 'auto-update' is set, use its value to set Sparkle's auto-update
behavior.
This fixes https://github.com/ghostty-org/ghostty/issues/3535 .
There exists an issue in ghostty on mac where if you have hidden your
titlebar, then enter fullscreen, the titlebar will reappear after
exiting fullscreen.
The reason for this is that after exiting fullscreen macos reapplies
some styling on the new window created after exiting fullscreen. To
combat this we will reapply the styling to hide the titlebar after
exiting fullscreen.
Required config:
```
macos-titlebar-style = hidden
macos-non-native-fullscreen = true
```
Steps to reproduce:
- Open Ghostty
- Enter fullscreen (non-native)
- Exit fullscreen
On main you will see the titlebar reappearing after exiting fullscreen,
while that does not happen with this patch.
Renames the top/bottom directions of `goto_split` to up/down. I have
tested this on linux (nixos) but given that `goto_split` is broken on
linux anyway (#2866) there's not a whole lot to test.
I have no way to build on macOS so I can't verify that I've changed
everything correctly for that.
Closes#3237
~~When processing toggle_fullscreen actions, multiple FullscreenStyle
derived objects would register observers on the same window and
subsequently remove them when the old style was deinited.~~
~~This change passes ownership of the fullscreenNotification observers
to TerminalController while still allowing FullscreenStyles access to
the window for style specific actions.~~
We need to have at least one fullscreen style (even if it is not being
used) to make sure that observers for fullscreen state changes are set
up. An alternative approach would be the first version of this PR (for
which my reasoning was wrong but the end change was correct) which
registers the fullscreen observers at either the TerminalController or
BaseTerminalController level.
Fixes#3553
# Description
The following code is causing an infinite loop that causes a CPU spikes
until the quick terminal is displayed:
87bd0bb744/macos/Sources/Features/QuickTerminal/QuickTerminalController.swift (L314-L317)
## Reproduce steps
1. Open Ghostty.
2. Open the Quick Terminal.
3. Close the Quick Terminal.
4. Reload the configuration (Ghostty > Reload Configuration or
`shift+cmd+,`).
5. Observe CPU spike.
## Fix
Now, `syncAppearance` doesn't postpone the process until it can be
consumed, and the appearance is synchronized once the animation is done
and the quick terminal is visible.
Fixes#3998
