Commit ad503b8c4f ("linux: consider Xft.dpi to scale the content")
introduced reading gtk-xft-dpi when the X11 build option is enabled.
While the name suggests it is X11-specific (perhaps it was at one
point), gtk-xft-dpi is a GTK setting that can be modified regardless of
GDK backend. GNOME’s Large Text accessibility setting ultimately
modifies it. Outside of desktop environments, it can be set via GTK
configuration files.
Remove the conditional gating the code on X11, since none of the code is
actually X11-specific. While we’re here, document scaling behaviors
under Config.font-size.
Fixes: ad503b8c4f ("linux: consider Xft.dpi to scale the content")
Fixes: https://github.com/ghostty-org/ghostty/issues/4338
Link: https://docs.gtk.org/gtk4/class.Settings.html
Link: https://docs.gtk.org/gtk4/property.Settings.gtk-xft-dpi.html
On non-MacOS desktop environments (Windows, Gnome, KDE, Xfce, VS Code,
...), `ctrl+ins` and `shift+ins` are system-wide alternate keybindings
(except for terminals) for `Copy` and `Paste` respectively. This PR
explicitly defines them as such in Ghostty's default keybindings.
Using `ctrl+ins` as an alt-keybinding for `Copy` allows
static/context-unaware remapping of `Copy` to `cmd+c` for Linux systems
using Mac keyboards via
[keyd](https://github.com/NixOS/nixpkgs/issues/137698#issuecomment-2404192700);
with the default `ctrl+shift+c` keybinding for copy this is basically
impossible (because that binding only applies to terminals).
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
macOS bitmap-only fonts are a poorly documented format, which are often
distributed as `.dfont` or `.dfon` files. They use a 'bhed' table in
place of the usual 'head', but the table format is byte-identical, so
enabling the use of bitmap-only fonts only requires us to properly fetch
this table while calculating metrics.
ref: https://fontforge.org/docs/techref/bitmaponlysfnt.html
Reverts #3550 for obvious reasons, and may close issue #2168 because
this should now mean that bitmap fonts are properly supported under both
font backends due to #3837 - unless `otb` fonts are still not properly
supported under FreeType (they are not supported under CoreText because
CoreText does not know how to handle them).
I tested this change with the `.dfont` distribution of
[Cozette](https://github.com/slavfox/Cozette) v1.25.2 and saw no visual
issues.
macOS bitmap-only fonts are a poorly documented format, which are often
distributed as `.dfont` or `.dfon` files. They use a 'bhed' table in
place of the usual 'head', but the table format is byte-identical, so
enabling the use of bitmap-only fonts only requires us to properly fetch
this table while calculating metrics.
ref: https://fontforge.org/docs/techref/bitmaponlysfnt.html
On my system (pop-os 22.04 LTS) with system theme and seperate light and
dark themes, ghostty always defaults to light mode. Switches between
light and dark mode are properly handled.
In the logs this error is reported:
error(gtk): unable to get current color scheme:
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method
“ReadOne”
The spec notes that the other functions are "[Deprecated, use ReadOne
instead.](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Settings.html)"
so using ReadOne is cerainly the correct path.
I've managed to fix this on my system by checking for the error and
falling back to an implementation using the deprecated Read.
Discussion: https://github.com/ghostty-org/ghostty/discussions/3704
Issue: https://github.com/ghostty-org/ghostty/issues/4038
When writing selected text to file, use `topLeft` and `bottomRight` instead of
`start` and `end` to ensure correct coordinate ordering. This fixes an issue
where selection files could be empty when selecting text in reverse order.
- Use `terminal.Selection.topLeft()` for start coordinate
- Use `terminal.Selection.bottomRight()` for end coordinate
Fixes#3953Fixes#3284
This fixes two issues. In fixing one issue, the other became apparent so
I fixed both in this one commit.
The first issue is that on macOS, the `open` command should take the
`-t` flag to open text files in a text editor. To do this, the `os.open`
function now takes a type hint that is used to better do the right
thing.
Second, the order of the paths that we attempt to open when editing a
config on macOS is wrong. Our priority when loading configs is well
documented:
https://ghostty.org/docs/config#macos-specific-path-(macos-only). But
open_config does the opposite. This makes it too easy for people to have
configs that are being overridden without them realizing it.
This commit changes the order of the paths to match the documented
order. If neither path exists, we prefer AppSupport.
We refresh the link hover state in two (generic) cases
1. When the modifiers change
2. When the cursor changes position
Each of these have additional state qualifiers. Modify the qualifiers
such that we refresh links under the following scenarios:
1. Modifiers change
- Control is pressed (this is handled in the renderer)
- Mouse reporting is off
OR
Mouse reporting is on AND shift is pressed AND we are NOT reporting
shift to the terminal
2. Cursor changes position
- Control is pressed (this is handled in the renderer)
- We previously were over a link
- The position changed (or we had no previous position)
- Mouse reporting is off
OR
Mouse reporting is on AND shift is pressed AND we are NOT reporting
shift to the terminal
This fixes a few issues with the previous implementation:
1. If mouse reporting was on and you were over a link, pressing ctrl
would enable link hover state. If you moved your mouse, you would
exit that state. The logic in the keyCallback and the
cursorPosCallback was not the same. Now, they both check for the same
set of conditions
2. If mouse reporting was off, you could hold control and move the mouse
to discover links. If mouse reporting was on, holding control + shift
would not allow you to discover links. You had to be hovering one
when you pressed the modifiers. Previously, we only refreshed links
if we *weren't* reporting the mouse event. Now, we refresh links even
even if we report a mouse event (ie a mouse motion event with the
shift modifier pressed *will* hover links and also report events)
## Old Behavior
Notice that the state of the hyperlink is erratic in `comlink`. When I
am over it and press ctrl the link is underlined and the url hint in the
lower left shown for one frame, but then the state is dropped.
https://github.com/user-attachments/assets/52d6a8c8-8459-4d67-85eb-5d91f9833771
## New Behavior
State is retained when holding ctrl+shift. And the link only underlines
if I press both ctrl+shift. If I move the mouse around while holding
these keys, I can discover new links.
https://github.com/user-attachments/assets/78fa8e97-eb0c-4618-bd96-fe40d6bc67ce
