See #6957
We were not considering GTK's internal scale factor that converts between
"surface coordinates" and actual device coordinates, and that worked fine
until the scale factor reached 2x (200%).
Since the code is now dependent on the scale factor (which could change
at any given moment), we also listen to scale factor changes and then
unconditionally call `winproto.syncAppearance`. Even though it's somewhat
overkill, I don't expect people to change their scale factor dramatically
all the time anyway...
Fixes a regression from #6909
See #6887
In certain scenarios, the last command key state would linger around (I
could only see this happen with global keybinds for unknown reasons
yet). This state is only meant to have an effect within the cycle of a
single keybind and only so we can ensure an event reaches keyDown so it
should be reset if keyDown is ever sent (since, by definition at that
point, keyDown has been reached).
I'm still not happy that this is necessary and I suspect there is a
better root cause to resolve, but I'd rather get this fix in now and
figure out the root cause later.
Fixes a regression from #6909
See #6887
In certain scenarios, the last command key state would linger around (I
could only see this happen with global keybinds for unknown reasons
yet). This state is only meant to have an effect within the cycle of a
single keybind and only so we can ensure an event reaches keyDown so it should
be reset if keyDown is ever sent (since, by definition at that point,
keyDown has been reached).
I'm still not happy that this is necessary and I suspect there is a
better root cause to resolve, but I'd rather get this fix in now and
figure out the root cause later.
Fixes problem pointed out in discussion #6895, as well as adjusting the
constraint logic to account for the offset, since I noticed it was
wrong; the constraint logic now accounts for the x offset, so that the
glyph does not exceed the right edge of the constraint width when the
offset is added, and the offset is zeroed if the glyph is resized down
to fit the constraint width.
|**Before**|**After**|
|-|-|
|<img width="84" alt="image"
src="https://github.com/user-attachments/assets/9561ca40-cfa0-4aed-b192-ee15042d8cbb"
/>|<img width="82" alt="image"
src="https://github.com/user-attachments/assets/9a77ac61-f46d-41de-a859-2b394024f7bc"
/>|
<sup>Zoom in to images for detail if you can't see the
crunchiness.</sup>
> [!NOTE]
> It may be an issue that that glyph is rendered with the constrained
text mode in the first place - Kitty doesn't seem to apply constraint
logic to it, and it seems a little over-eager to do so on our part. This
is something to look in to.
We can't use nearest neighbor filtering for sampling from the atlas
because we might not actually be doing pixel perfect sampling if the
glyph has been constrained. This will change in the future, but this
will have to be set to linear for now.
Fixes#5522
This commit re-dispatches command inputs that are unhandled by our macOS
app so they can be encoded to the pty and handled by the core libghostty
key callback system.
We've had a special case `cmd+period` handling in Ghostty for a very
long time (since well into the private beta). `cmd+period` by default
binds to "cancel" in macOS, so it doesn't encode to the pty. We don't
handle "cancel" in any meaningful way in Ghostty, so we special-cased it
to encode properly to the pty.
However, as shown in #5522, if the user rebinds `cmd+period` at the
system level to some other operation, then this is ignored and we encode
it still. This isn't desirable, we just want to work around not caring
about "cancel."
The callback path that AppKit takes for key events is a bit convoluted.
For command keys, it first calls `performKeyEquivalent`. If this returns
false (we want to continue standard processing), then it calls EITHER
`keyDown` or `doCommand(by:)`. It calls the latter if there is a
standard system command that matches the key event. For `cmd+period` by
default, this is "cancel." Unfortunately, from `doCommand` we can't say
"oops, we don't want to handle this, please continue processing." Its
too late.
So, this commit stores the last command key event from
`performKeyEquivalent` and if we reach `doCommand` for it without having
called `keyDown`, we re-dispatch the event and send it to keyDown.
I'm honestly pretty sus about this whole logic but it is scoped to only
command-keys and I couldn't trigger any adverse behavior in my testing.
It also definitely fixed#5522 as far as I could reproduce it before.
Fixes#5522
This commit re-dispatches command inputs that are unhandled by our macOS
app so they can be encoded to the pty and handled by the core libghostty
key callback system.
We've had a special case `cmd+period` handling in Ghostty for a very
long time (since well into the private beta). `cmd+period` by default
binds to "cancel" in macOS, so it doesn't encode to the pty. We don't
handle "cancel" in any meaningful way in Ghostty, so we special-cased it
to encode properly to the pty.
However, as shown in #5522, if the user rebinds `cmd+period` at the
system level to some other operation, then this is ignored and we encode
it still. This isn't desirable, we just want to work around not caring
about "cancel."
The callback path that AppKit takes for key events is a bit convoluted.
For command keys, it first calls `performKeyEquivalent`. If this returns
false (we want to continue standard processing), then it calls EITHER
`keyDown` or `doCommand(by:)`. It calls the latter if there is a
standard system command that matches the key event. For `cmd+period` by
default, this is "cancel." Unfortunately, from `doCommand` we can't say
"oops, we don't want to handle this, please continue processing." Its
too late.
So, this commit stores the last command key event from
`performKeyEquivalent` and if we reach `doCommand` for it without having
called `keyDown`, we re-dispatch the event and send it to keyDown.
I'm honestly pretty sus about this whole logic but it is scoped to only
command-keys and I couldn't trigger any adverse behavior in my testing.
It also definitely fixed#5522 as far as I could reproduce it before.
This updates our bundled Harfbuzz from 8.4 to 11.0. The changes from 8
to 11 include a number of correctness and performance improvements.
Packaged releases tend to dynamically link so this won't affect existing
users, but build-from-source users hopefully get an improvement.
This updates our bundled Harfbuzz from 8.4 to 11.0. The changes from 8
to 11 include a number of correctness and performance improvements.
Packaged releases tend to dynamically link so this won't affect
existing users, but build-from-source users hopefully get an
improvement.
We have always tracked a post-3.4 release, this brings us up to date.
There's no real motivation beyond this other than keeping up to date
since we're already on non-release versions anyways. The diff is
dominated by auto-generated headers from Wayland-scanner.
We have always tracked a post-3.4 release, this brings us up to date.
There's no real motivation beyond this other than keeping up to date
since we're already on non-release versions anyways.
Fixes#6872
This commit explicitly acquires the GL context in the `unrealize` signal
handler of the GTK Surface prior to cleaning up GPU resources.
A GLArea only guarantees that the associated GdkContext is current for
the `render` signal (see the docs[1]). This is why our OpenGL renderer
"defers" various operations such as resize, font grid changing, etc.
(see the `deferred_`-prefix fields in `renderer/OpenGL.zig`). However,
we missed a spot.
The `gtk-widget::unrealize` signal is emitted when the widget is
destroyed, and it is the last chance we have to clean up our GPU
resources. But it is not guaranteed that the GL context is current at
that point, and we weren't making it current. On the NGL GTK renderer,
this was freeing GPU resources we didn't own.
As best I can understand, the old GL renderer only ever used a handful
of GL resources that were early in the ID space, so by coincidence we
were probably freeing nothing and everything was fine. But with the new
NGL renderer uses a LOT more GL resources (make a few splits and the ID
space is already in the thousands, from GTK!), so we were freeing real
resources that we didn't own, which caused rendering issues. :)
I suspect the above also resulted in VRAM memory leaks (which would be
RAM memory leaks for unified memory GPUs). This potentially relates to
#5491.
The fix is to explicitly make the GL context current in the `unrealize`
handler.
[1]: https://docs.gtk.org/gtk4/method.GLArea.make_current.html
This was a hack, and is no longer required since #6877. Users can
explicitly override the GTK GSK renderer by setting the standard GTK env
var `GSK_RENDERER`.
Fixes#6872
This commit explicitly acquires the GL context in the `unrealize`
signal handler of the GTK Surface prior to cleaning up GPU resources.
A GLArea only guarantees that the associated GdkContext is current for
the `render` signal (see the docs[1]). This is why our OpenGL renderer
"defers" various operations such as resize, font grid changing, etc.
(see the `deferred_`-prefix fields in `renderer/OpenGL.zig`).
However, we missed a spot.
The `gtk-widget::unrealize` signal is emitted when the widget is
destroyed, and it is the last chance we have to clean up our GPU
resources. But it is not guaranteed that the GL context is current at
that point, and we weren't making it current. On the NGL GTK renderer,
this was freeing GPU resources we didn't own.
As best I can understand, the old GL renderer only ever used a handful
of GL resources that were early in the ID space, so by coincidence we
were probably freeing nothing and everything was fine. But with the new
NGL renderer uses a LOT more GL resources (make a few splits and the ID
space is already in the thousands, from GTK!), so we were freeing real
resources that we didn't own, which caused rendering issues. :)
I suspect the above also resulted in VRAM memory leaks (which would be
RAM memory leaks for unified memory GPUs). This potentially relates to
#5491.
The fix is to explicitly make the GL context current in the `unrealize`
handler.
[1]: https://docs.gtk.org/gtk4/method.GLArea.make_current.html
> 3. If you want to live dangerously, open a pull request and hope for
the best.
Sure, why not!
---
This is a *super common* ask in both the GitHub Discussions and on
Discord; I thus decided to add a small(ish) note to the help output
directing users to try the open command. I did not include a note to
check the man page, as the text was already getting a bit long, but I
can change that if requested. Strings open for bike-shedding, of course.
Of course, feel free to close this if this is not a desirable change for
the project; I would appreciate a note about that though, rather than a
random unexpected close without any reason, as that would prevent any
future PRs about this from others.
As I do not use macOS, I was unable to test the appearance of the string
I edited in `main_ghostty.zig`.
On a slightly related note: are there any plans to translate the CLI's
strings? I assume they're in the same boat as the configuration parsing
errors which were [discussed in #maintainers] on [the Ghostty Discord].
[discussed in #maintainers]:
https://discord.com/channels/1005603569187160125/1337443701403815999/1352390511553417327
[the Ghostty Discord]: https://discord.org/ghostty
We don't currently support rendering SVG glyphs so they should be
ignored when loading. Additionally, the check for whether a glyph is
colored has been simplified by just checking the pixel mode of the
rendered bitmap.
This commit also fixes a bug caused by calling the color check inside of
`renderGlyph`, which caused the bitmap to be freed creating a chance for
memory corruption and garbled glyphs. This bug was introduced by 40c1140
(#6602) and discussed in #6781.
Fixes#6821
UTF8 translation using KeymapDarwin requires a buffer and the buffer was
stack allocated in the coreKeyEvent call and returned from the function.
We need the buffer to live longer than this.
Long term, we're removing KeymapDarwin (there is a whole TODO comment in
there about how to do it), but this fixes a real problem today.
Fixes#6821
UTF8 translation using KeymapDarwin requires a buffer and the buffer was
stack allocated in the coreKeyEvent call and returned from the function.
We need the buffer to live longer than this.
Long term, we're removing KeymapDarwin (there is a whole TODO comment in
there about how to do it), but this fixes a real problem today.
Also update shaper test that fails because the run iterator can't apply
that logic since `testWriteString` doesn't do proper grpaheme clustering
so the parts are actually split across multiple cells.
Several other tests are technically incorrect for the same reason but
still pass, so I've decided not to fix them here.
This tweak is minor and fixes some grammatical errors.
I did not change `kopier` to `kopiér`, even though that is a common way
to write the word. The language council of Norway suggest writing the
word as it is written here, without the accent, but it does read weird
and allows for misunderstanding. If this was my project I would have
added the accent. Let me know if you want the accent added.
What do you think regarding the accents @Uzaaft ?
