This should make testing Flatpak builds a lot easier.
To build, enter `flatpak/` directory and run:
flatpak-builder --repo=repo builddir com.mitchellh.ghostty.yml
alternatively, using org.flatpak.Builder flatpak:
flatpak run -p org.flatpak.Builder \
--repo=repo \
builddir \
com.mitchellh.ghostty.yml
The resulting flatpak can be installed using
flatpak install ./repo com.mitchellh.ghostty
Credit of AppStream metadata goes to @yorickpeterse.
This introduces a command palette (inspired by @pluiedev's work in
#5681, but not using it as a base) for macOS.
The command palette is available in the `View` menu and also bindable
via `toggle_command_palette`, default binding is `cmd+shift+p` to match
VSCode.
The commands in the command palette must map to a _bindable_ action,
though they may not have an associated keybinding. This means that any
new binding actions we add in the future can be represented here and
also makes it easy in the future to add configuration to add new custom
entries to the command palette. For this initial PR, the available
commands are hardcoded (`src/input/commands.zig`).
I've noticed in other programs (VSCode, Zed), the command palette
contains pretty much _all available actions_ even if they're basically
useless in the context of a command palette. For example, Zed has the
"toggle command palette" action in the command palette and it... does
nothing (it probably should hide the palette). I followed @pluiedev's
lead and made this subjective in this PR but I wonder if we should
actually force all binding actions to be available.
There are various other improvements I'd like to make but omitted from
this PR for the sake of limiting scope:
* Instead of an entry with no matches doing nothing, we can allow users
to manually input _any_ configurable binding.
* Localization, since macOS doesn't have any yet. But for Linux when we
port this we probably have to change our strings extraction.
## Demo
https://github.com/user-attachments/assets/a2155cfb-d86b-4c1a-82b5-74ba927e4d69
Resolves#7108
This PR adds visual notification badges to the Ghostty dock icon when
bell events are triggered while the application is in the background.
This complements the existing dock bounce notification, making it easier
for users to notice when a terminal needs attention.
https://github.com/user-attachments/assets/b54c881f-fea8-4085-8614-432d9e5847b9
Fixes#2446
Supersedes #7144
Two separate issues:
1. Ensure that our screen size matches the viewport size when drawFrame
is called. By the time drawFrame is called, GTK will have updated the
OpenGL context, but our deferred screen size may still be incorrect
since we wait for the pty to update the screen size.
2. Do not clear our cells buffer when the screen size changes, instead
changing to a mechanism that only clears the buffers when we have over
50% wasted space.
/cc @adlr I added you as a coauthor.
Fixes#2446
Two separate issues:
1. Ensure that our screen size matches the viewport size when
drawFrame is called. By the time drawFrame is called, GTK will have
updated the OpenGL context, but our deferred screen size may still
be incorrect since we wait for the pty to update the screen size.
2. Do not clear our cells buffer when the screen size changes, instead
changing to a mechanism that only clears the buffers when we have
over 50% wasted space.
Co-authored-by: Andrew de los Reyes <adlr@rivosinc.com>
Fixes a regression where `C-S-c` stopped working properly in both legacy
and Kitty modes (although the Kitty mode side only affected alternates
and not the key itself so it probably worked fine in most programs).
The issue is that `charactersIgnoringModifiers` changes behavior if
`control` is pressed, so it doesn't really ignore all modifiers. We have
to use `characters(byApplyingModifiers:)` to get the proper unshifted
codepoint when `control` is pressed.
This replaces the use of our custom `Ghostty.KeyEquivalent` with the
SwiftUI `KeyboardShortcut` type. This is a more standard way to
represent keyboard shortcuts and lets us more tightly integrate with
SwiftUI/AppKit when necessary over our custom type.
This PR should have no user impact. This is just some cleanup for future
work.
Note that not all Ghostty triggers can be represented as
KeyboardShortcut values because macOS itself does not support binding
keys such as function keys (e.g. F1-F12) to KeyboardShortcuts.
This isn't an issue since all input also passes through a lower level
libghostty API which can handle all key events, we just can't show these
keyboard shortcuts on things like the menu bar. This was already true
before this commit.
Fixes a regression where `C-S-c` stopped working properly in both legacy
and Kitty modes (although the Kitty mode side only affected alternates
and not the key itself so it probably worked fine in most programs).
The issue is that `charactersIgnoringModifiers` changes behavior if
`control` is pressed, so it doesn't really ignore all modifiers. We have
to use `characters(byApplyingModifiers:)` to get the proper unshifted codepoint
when `control` is pressed.
This replaces the use of our custom `Ghostty.KeyEquivalent` with
the SwiftUI `KeyboardShortcut` type. This is a more standard way to
represent keyboard shortcuts and lets us more tightly integrate with
SwiftUI/AppKit when necessary over our custom type.
Note that not all Ghostty triggers can be represented as
KeyboardShortcut values because macOS itself does not support
binding keys such as function keys (e.g. F1-F12) to KeyboardShortcuts.
This isn't an issue since all input also passes through a lower level
libghostty API which can handle all key events, we just can't show these
keyboard shortcuts on things like the menu bar. This was already true
before this commit.
This reverts commit 14134d61fb4b1bbf4ce80bb9b3ed849908bf9344, reversing
changes made to 6a876ef8ec3e2aeb3d15df0dfb0e07677e49ff03.
This causes translation failures, this should be reintroduced when the
CI check passes.
