yet another follow up to #4534
some notes:
- different parts of the build system link against freetype2 or freetype
with freetype2 being the name for the pkg-config file. Because of the
include path in freetype-zig.h the pkg-config is needed otherwise it
would be unable to find the headers. The change isn't technically needed
for the harfbuzz and fontconfig modules however I think its best to keep
them all consistent since otherwise it might cause build errors in non
standard setups
- looking back, I initially modelled buildLib after the build function
and kept the pub, none of them need to be public so I've gone ahead and
removed all of that
test logic was kept just as they were before with a setup exact like it
was done for oniguruma
the main program and the testsall seem to work just fine both with and
without system integration
Sorry for the vague title. This PR addresses multiple issues:
1. Fixes#4540
2. #4522 is fixed for macOS only
3. Fixes#4590
4. Fixes an untracked issue where `command+key` events will not send
release events for Kitty keyboard protocol, something I only noticed
while working on this.
There are multiple components to this PR.
## Part 1: `App/Surface.keyEventIsBinding`
This new API (also available in libghostty as
`ghostty_surface_key_is_binding`) returns a boolean true if the given
key event would match a binding trigger if it was the next key event
sent. It does not process the binding now.
This can be used by event handlers that intercept key events to
determine if it should send the event to Ghostty. This helps resolve
#4590 for us but is also part of all resolved issues.
## Part 2: macOS `performKeyEquivalent` changes
macOS calls `performKeyEquivalent` for any key combination that may
trigger a key equivalent. if this returns `true` then it is handled and
macOS ceases processing the event.
We were already using this to intercept things like `Ctrl+/` which
triggers a context menu in macOS Sequoia. But we now expand this to
intercept all events to check for bindings. This lets us fix#4590.
Additionally, it's been changed to special case `cmd+period`. I'm sure
more need to be added.
## Part 3: NSEvent local listener for command keyUp events
macOS simply doesn't send `keyUp` events for key events with command
pressed. The only way to work around this is to register an `NSEvent`
local listener. We now do this. This fixes the untracked issue noted
above.
As a new user of ghostty, it was not intuitive to figure out how to
provide the `offset` parameter. It makes sense when you look more of the
rest of the options but I think we can still make these docs cleaner,
like I have done in this PR.
Thanks!
This changes quit signaling from a boolean return from core app `tick()`
to an apprt action. This simplifies the API and conceptually makes more
sense to me now.
This wasn't done just for that; this change was also needed so that
macOS can quit cleanly while fixing #4540 since we may no longer trigger
menu items. I wanted to split this out into a separate commit/PR because
it adds complexity making the diff harder to read.
This changes quit signaling from a boolean return from core app `tick()`
to an apprt action. This simplifies the API and conceptually makes more
sense to me now.
This wasn't done just for that; this change was also needed so that
macOS can quit cleanly while fixing #4540 since we may no longer trigger
menu items. I wanted to split this out into a separate commit/PR because
it adds complexity making the diff harder to read.
This changes quit signaling from a boolean return from core app `tick()`
to an apprt action. This simplifies the API and conceptually makes more
sense to me now.
This wasn't done just for that; this change was also needed so that
macOS can quit cleanly while fixing #4540 since we may no longer trigger
menu items. I wanted to split this out into a separate commit/PR because
it adds complexity making the diff harder to read.
running `zig build --help` was crashing for some people, I narrowed it
down to gtk4 not being installed however that shouldn't make the help
message not nor should it block glfw builds
In #4388, documentation was added for goto_split but in #3427 this
documentation was made outdated but not updated. This makes the
documentation up to date and brings the ordering in line with new_split
follow-up to #4520
all the same stuff for the previous two
the tests for this only run for the native target and was added for the
iOS build (3360a008cd137b428631fc8052f64d672a660240), I've made a second
version of this commit to remove the native check if thats more desired
(d247a22de036140297942701090e0eafb3d1a72d)
ghostty and all tests appear to run on my system both with and without
system integration
In #4388, documentation was added for goto_split but in #3427 this
documentation was made outdated but not updated. This makes the
documentation up to date and brings the ordering in line with new_split
This is achieved by rendering to an alpha-only context rather than a
normal single-channel context, and adjusting the brightness at which
coretext thinks it's drawing the glyph, which affects how it applies
font smoothing (which is what `font-thicken` enables).
Fixes#4518
If our UTF8 encoding is not recognized, we fall back to the ASCII
mapping of the logical key for the control sequence. This allows
cyrillic control characters to work.
I also verified that non-cyrllic (US) and alternate layouts (Dvorak)
work as expected still.
same as #4205 but for fontconfig
it follows the same pattern with one addition:
the module needs a known target to be able to link a system library
I don't think this will affect anything
ghostty and all tests appear to run on my system both with and without
system integration
Fixes#4518
If our UTF8 encoding is not recognized, we fall back to the ASCII
mapping of the logical key for the control sequence. This allows
cyrillic control characters to work.
I also verified that non-cyrllic (US) and alternate layouts (Dvorak)
work as expected still.
