Recently when answering [a Discussion], I was reminded of when Tristan
once linked the GTK CSS documentation and said “Perhaps good to add this
to the docs of the GTK custom CSS config option”, so I decided to do
that now. I also added a few random things that I found helpful when
attempting to modify Ghostty's CSS; this information was mostly stolen
from random people on Discord or accidentally discovered.
I really do not care if this is merged or not, nor do I care if the
strings are changed considerably[^1], so I am going straight for a Pull
Request without bothering to open a Discussion, get that converted to an
Issue after a few years, then finally remember to open a Pull Request.
I only tested what this looks like in `ghostty +show-config --default
--docs`, the manpage and the HTML output; I notably did not try seeing
how it renders on the website. The links have to be in angle brackets
for the HTML output to have it rendered as URLs, but it looks odd
everywhere else; manpages have them with mathematical angle brackets,
⟨like this⟩. I also refrained from using an em (—) or en (–) dash
instead of a normal dash (-) as that does not seem to be common in the
rest of the documentation.
[a Discussion]: https://github.com/ghostty-org/ghostty/discussions/7189
[^1]: I didn't see any guidelines or standards for these strings, so
presumably these would be contested as I didn't know what to adhere to
when writing them.
XTGETTCAP queries are a semicolon-delimited list of hex encoded terminfo
capability names. Ghostty encodes a map using upper case hex encodings,
meaning when an application uses a lower case encoding the capability is
not found. To fix, we convert the entire list we receive in the query to
upper case prior to processing further.
Fixes: #7229
It may not be immediately obvious how to style Ghostty despite knowing
of the existence of that configuration option; one who is more
accustomed to web development would likely be very reliant on their
browser's inspector for modifying and debugging the style of their
application. GTK CSS also differs in some important ways from the CSS
found in browsers, and hence linking to the GTK CSS documentation would
save time for anyone new to styling GTK applications.
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)
Changes:
1. Require `blueprint-compiler` 0.16.0 (or newer) for building from
a git checkout. With #6822 distributions that can't meet that
requirement can use generated source tarballs to build.
2. Remove all `.ui` files as they are unnecessary.
3. Simplify the `Builder` interface since raw `.ui` files are no
longer used.
4. Removed build-time check of raw `.ui` files.
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
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>
This is a large refactor of the keyboard input handling code in
libghostty and macOS. Previously, libghostty did a lot of things that
felt out of scope or was repeated work due to lacking context. For
example, libghostty would do full key translation from key event to
character (including unshifted translation) as well as managing dead key
states and setting the proper preedit text.
This is all information the apprt can and should have on its own.
NSEvent on macOS already provides us with all of this information,
there's no need to redo the work. The reason we did in the first place
is mostly historical: libghostty powered our initial macOS port years
ago when we didn't have an AppKit runtime yet.
This cruft has already practically been the source of numerous issues,
e.g.
https://github.com/ghostty-org/ghostty/issues/5558, but many other hacks
along the way, too.
This commit pushes all preedit (e.g. dead key) handling and key
translation
including unshifted keys up into the caller of libghostty.
Besides code cleanup, a practical benefit of this is that key event
handling on macOS is now about 10x faster on average. That's because
we're avoiding repeated key translations as well as other unnecessary
work. This should have a meaningful impact on input latency but I didn't
measure the full end-to-end latency.
A scarier part of this commit is that key handling is not well tested
since its a GUI component. I suspect we'll have some fallout for certain
keyboard layouts or input methods, but I did my best to run through
everything I could think of.
This also fixes one bug where preedit state didn't properly clear when
changing keyboard layouts. This now does and matches the behavior
of native apps like TextEdit and Terminal.app
This is a large refactor of the keyboard input handling code in
libghostty and macOS. Previously, libghostty did a lot of things that
felt out of scope or was repeated work due to lacking context. For
example, libghostty would do full key translation from key event to
character (including unshifted translation) as well as managing dead key
states and setting the proper preedit text.
This is all information the apprt can and should have on its own.
NSEvent on macOS already provides us with all of this information,
there's no need to redo the work. The reason we did in the first place
is mostly historical: libghostty powered our initial macOS port years
ago when we didn't have an AppKit runtime yet.
This cruft has already practically been the source of numerous issues, e.g.
#5558, but many other hacks along the way, too.
This commit pushes all preedit (e.g. dead key) handling and key translation
including unshifted keys up into the caller of libghostty.
Besides code cleanup, a practical benefit of this is that key event
handling on macOS is now about 10x faster on average. That's because
we're avoiding repeated key translations as well as other unnecessary
work. This should have a meaningful impact on input latency but I didn't
measure the full end-to-end latency.
A scarier part of this commit is that key handling is not well tested
since its a GUI component. I suspect we'll have some fallout for certain
keyboard layouts or input methods, but I did my best to run through
everything I could think of.
Fixes#7099
This adds basic bell features to macOS to conceptually match the GTK
implementation. When a bell is triggered, macOS will do the following:
1. Bounce the dock icon once, if the app isn't already in focus.
2. Add a bell emoji (🔔) to the title of the surface that triggered
the bell. This emoji will be removed after the surface is focused
or a keyboard event if the surface is already focused. This
behavior matches iTerm2.
This doesn't add an icon badge because macOS's dockTitle.badgeLabel API
wasn't doing anything for me and I wasn't able to fully figure out
why...
Fixes#7066
This fixes an issue where under certain conditions (expanded below), we
would not clear the correct row, leading to the screen having duplicate
data.
This was triggered by a page state of the following:
```
+----------+ = PAGE 0
... : :
4305 |1ABCD00000|
4306 |2EFGH00000|
:^ : = PIN 0
+-------------+ ACTIVE
4307 |3IJKL00000| | 0
+----------+ :
+----------+ : = PAGE 1
0 | | | 1
1 | | | 2
+----------+ :
+-------------+
```
Namely, the cursor had to NOT be on the last row of the first page,
but somewhere on the first page. Then, when an `index` (LF) operation
was performed the result would look like this:
```
+----------+ = PAGE 0
... : :
4305 |1ABCD00000|
4306 |2EFGH00000|
+-------------+ ACTIVE
4307 |3IJKL00000| | 0
:^ : : = PIN 0
+----------+ :
+----------+ : = PAGE 1
0 |3IJKL00000| | 1
1 | | | 2
+----------+ :
+-------------+
```
The `3IJKL` line was duplicated. What was happening here is that we
performed the index operation correctly but failed to clear the cursor
line as expected.
This is because we were always clearing the first row in the page
instead of the row of the cursor.
Test added.
This PR implements a more lightweight alternative to #5326 that contains
features that I personally think Just Make Sense for the bell.
No configs, no GStreamer stuff, just sane defaults to get us started.
Fixes#7077
This follows pretty standard behavior across native or popular applications
on both platforms macOS and Linux. The basic behavior is that if you
do a mouse down event and then drag the mouse beyond the current
character, then any mouse up actions are canceled (beyond emiting the
event itself).
This fixes a specific scenario where you could do the following:
1. Click anywhere (mouse down)
2. Drag over a valid link
3. Press command/control (to activate the link)
4. Release the mouse button (mouse up)
5. The link is triggered
Now, step 3 and step 5 do not happen. Links are not even highlighted in
this scenario. This matches iTerm2 on macOS which has a similar
command-to-activate-links behavior.
Hi!
I have followed the instructions and added translations for Spanish,
Country Latin America 419 according to
[this](https://localizely.com/locale-code/es-419/) and other online
sources.
In the provided links there was no references to 419, but I created it
via the suggested command:
`msginit -i po/com.mitchellh.ghostty.pot -l es_419.UTF-8 -o
"po/es_419.UTF-8.po" `
Glad to be able to contribute to this excellent product!
Cheers!
