A simple change to make the text preview in the paste confirmation
dialog monospace; this feels like something that most users would want,
or at least very few users would dislike.
We just call `gtk_text_view_set_monospace` and let GTK use whatever
default monospace font it wants to use. Theoretically we could probably
tell it to use whatever font the user has configured, but this should be
sufficient for most users.
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
## Description
Fix an issue where `write_selection_file` would create empty files when
selecting multiple lines. This occurred because the selection
coordinates were not properly ordered when writing to file.
## Problem
When selecting multiple lines from bottom to top , the resulting file
would be empty. This happened because:
1. Selection coordinates were used directly without proper ordering
2. `start()` and `end()` don't guarantee top-to-bottom, left-to-right
ordering
## Solution
Use `topLeft()` and `bottomRight()` methods to ensure correct coordinate
ordering when writing selection to file.
## Testing
Tested the following scenarios:
- Selecting multiple lines from top to bottom ✅
- Selecting multiple lines from bottom to top ✅
## Known Behavior
When selecting a single word, the entire line containing that word is
written to the file. This is consistent with the current terminal
behavior as noted in the [original
discussion](https://github.com/ghostty-org/ghostty/discussions/3594).
Fixesghostty-org/ghostty#3594
