C bindings to expose the color palette to Swift for macOS. Returns the
full 256 colors from the current color scheme. After fetching the
palette with `ghostty_config_get`, you can access the desired color by
its index in the list.
### Usage
Here is one way to get the palette in Swift.
```swift
import GhosttyKit
private(set) var config: ghostty_config_t? = nil {
didSet {
// Free the old value whenever we change
guard let old = oldValue else { return }
ghostty_config_free(old)
}
}
var paletteColors: [Color] {
var paletteList: ghostty_config_palette_s = .init()
let key = "palette"
if (!ghostty_config_get(config, &paletteList, key, UInt(key.count))) {
return []
}
var colors: [Color] = []
let mirror = Mirror(reflecting: paletteList.colors)
for (_, element) in mirror.children {
if let color = element as? ghostty_config_color_s {
colors.append(Color(
red: Double(color.r) / 255,
green: Double(color.g) / 255,
blue: Double(color.b) / 255
))
}
}
print("Palette Colors: ", colors)
return colors
}
```
Result (GruvboxDarkHard theme)
version 0.6.0 of z2d has a security vulnerability and the author
suggests upgrading (randomly saw this in the zig discord)
https://github.com/vancluever/z2d/security/advisories/GHSA-mm4c-p35v-7hx3
I don't know enough about how ghostty uses to it to say if it could be
affected
also updates that Context no longer returns an error type this says it
was in the 0.6.0 changes which ghostty was already pinned to (it seems
like that the tag might have been updated or something im not sure) you
can see it listed as a change in 0.6.0 below
https://github.com/vancluever/z2d/blob/main/CHANGELOG.md
I'm not sure if any other changes are required I ran a `zig build` and
`zig build test` and things seem to be fine on my end
~~I'm not sure I updated the zon nix stuff correctly I just ran the
command in jcollie readme
`nix run github:jcollie/zon2nix#zon2nix -- --nix=build.zig.zon.nix
build.zig.zon`~~ looks like I should have just ran the script
ps: sorry for the direct ping mitchell (I thought this might be
important that you look at it)
Resolve 1. of #7173
<img width="1126" alt="image"
src="https://github.com/user-attachments/assets/8904b09f-42f6-4f26-a722-c92dad8e2933"
/>
Changes made:
1. Change shortcut from `String` to `[String]` so its easier to iterate
over it.
2. Overlay background color on top of an `ultraThinMaterial` for better
aesthetic.
3. Reorganize and beautify the spacings and paddings.
4. Unhide the scrollbar.
5. Reorder the modifier keys to Control, Option, Shift and then Command.
<https://leancrew.com/all-this/2017/11/modifier-key-order/>
6. Style shortcut keys to resemble macOS menu bar items, using
corresponding symbols and fixed-width for alignment.
#7173
(1) The command palette no longer has any selection by default. If and
when we introduce most recently used commands, defaulting to that would
make sense. A selection only appears when the arrow keys are used or the
user starts typing.
(2) The selection with arrow keys now wraps, so if you press "down" on
the last option, it will wrap to the first option, and if you press "up"
on the first option, it will wrap to the last option. This matches both
VSCode and Zed.
#7173
(1) The command palette no longer has any selection by default.
If and when we introduce most recently used commands, defaulting to that
would make sense. A selection only appears when the arrow keys are used
or the user starts typing.
(2) The selection with arrow keys now wraps, so if you press "down" on
the last option, it will wrap to the first option, and if you press "up"
on the first option, it will wrap to the last option. This matches both
VSCode and Zed.
As discussed in #7165, this PR resolves two issues with the command
pallete on macOS.
1. The flashing of a command passing out of view was caused by the
`withAnimation` function. Removing this closure resolved this issue.
2. The current implementation kept the selected command anchored to the
middle of the pallete. However, most command pallates allow you to key
through the visible options, only scrolling when your selection hits the
boundary. I resolved this by removing the `anchor: .center` parameter
for the `scrollTo` command.
Removes the withAnimation closure which caused flashing when scrolling
up or down with arrow keys. Also removes the center anchor to behave
more like other command palletes (e.g., Zed, Raycast).
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 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>
