I don't see any actual changes here, just reordering. It's using the Nix
environment so I'm not sure why this happened but it seemed to stem from
the Norwegian work originally. Fixing it back.
I don't see any actual changes here, just reordering. It's using the Nix
environment so I'm not sure why this happened but it seemed to stem from
the Norwegian work originally. Fixing it back.
Discover resourcesdir with `terminfo/g/ghostty`
as well as existing `terminfo/x/xterm-ghostty`.
This allows either terminfo file to be installed,
notably ncurses only provides a `terminfo/g/ghostty`.
This adds a CI test to ensure that all Zig files are properly formatted.
This avoids unrelated diff noise in future PRs.
This also runs `zig fmt` once to clean up all formatting issues for
future PRs.
I also introduced a new `xsm` (extra small) runner profile to use less
resources for our tiny tasks.
1. Refactored Nix devshell/package to make it easier to keep
LD_LIBRARY_PATH & buildInputs in sync (plus make it easier to re-use in
other Nix environment).
2. Added a CI job to ensure that Blueprints are formatted correctly and
that they will compile using `blueprint-compiler` 0.16.0.
3. Reformatted all Blueprints with `blueprint-compiler format`.
1. Refactored Nix devshell/package to make it easier to keep
LD_LIBRARY_PATH & buildInputs in sync (plus make it easier to re-use
in other Nix environment).
2. Added a CI job to ensure that Blueprints are formatted correctly and
that they will compile using `blueprint-compiler` 0.16.0.
3. Reformatted all Blueprints with `blueprint-compiler format`.
This moves the source tarball creation process into the Zig build system
and follows the autotools-standard naming conventions of `dist` and
`distcheck`.
This doesn't change any of our build process otherwise. This is the
foundation for #6760 along with other source tarball tasks I have
planned (i.e. gobject bindings too).
The `dist` target creates a source tarball in the `PREFIX/dist`
directory. The tarball is named `ghostty-VERSION.tar.gz` as expected by
standard source tarball conventions.
The `distcheck` target does the same as `dist`, but also takes the
resulting tarball, extracts it, and runs tests on the extracted source
to verify the source tarball works as expected. Distcheck currently only
runs `zig build test` but in the future we can add additional checks to
run.
This commit also updates CI:
1. Tagged releases now use the new `zig build distcheck` command.
2. Tip releases now use the new `zig build dist` command.
3. A new test build tests that source tarball generation works on every
commit.
This moves the source tarball creation process into the Zig build system
and follows the autotools-standard naming conventions of `dist` and
`distcheck`.
The `dist` target creates a source tarball in the `PREFIX/dist`
directory. The tarball is named `ghostty-VERSION.tar.gz` as expected by
standard source tarball conventions.
The `distcheck` target does the same as `dist`, but also takes the
resulting tarball, extracts it, and runs tests on the extracted source
to verify the source tarball works as expected.
This commit also updates CI:
1. Tagged releases now use the new `zig build distcheck` command.
2. Tip releases now use the new `zig build dist` command.
3. A new test build tests that source tarball generation works on
every commit.
As of Adwaita 1.5.0, the GTK Box is not being properly unref'd when the
parent window is closed. Update the conditional to account for this.
Also add a couple of missing unref()s in errdefers.
This fixes an issue where Ghostty would not properly quit after closing
the last surface.
https://github.com/ghostty-org/ghostty/discussions/3807 is related
(though I'm not sure it's the exact same problem).
As of Adwaita 1.5.0, the GTK Box is not being properly unref'd when the
parent window is closed. Update the conditional to account for this.
Also add a couple of missing unref()s in errdefers.
Fixes#6772
When typing Korean with the fcitx5-hangful input method, moving between
graphemes does not trigger a preedit end/start cycle and instead just
clears the preexisting preedit and reuses the started state.
Every other input method we've tested up until now doesn't do this. We
need to mark composing set to "false" in "commit" because some input
methods on the contrary fail to ever call END.
What is the point of start/end events if they are just ignored depending
on the whim of the input method? Nothing. That's what. Its all a mess
that GTK should be protecting us from but it doesn't and now its the app
developer's problem. I'm frustrated because I feel like the point of an
app framework is to mask this kind of complexity from the app developer
and I'm playing whack-a-mole with input methods.
Well, here's another whack. Let's see if it works.
Fixes#6772
When typing Korean with the fcitx5-hangful input method, moving between
graphemes does not trigger a preedit end/start cycle and instead just
clears the preexisting preedit and reuses the started state.
Every other input method we've tested up until now doesn't do this. We
need to mark composing set to "false" in "commit" because some input
methods on the contrary fail to ever call END.
What is the point of start/end events if they are just ignored depending
on the whim of the input method? Nothing. That's what. Its all a mess
that GTK should be protecting us from but it doesn't and now its the app
developer's problem. I'm frustrated because I feel like the point of an
app framework is to mask this kind of complexity from the app developer
and I'm playing whack-a-mole with input methods.
Well, here's another whack. Let's see if it works.
1. Remove usage of C header imports for gtk x11/wayland.
2. Move X11 C header imports to winproto_x11.zig
3. Clean up long line by breaking it up into multiple steps.
Some wheel mice are capable of reporting fractional wheel ticks. These
mice don't necessarily report a corresponding precision scroll start
event, at least in Wayland + GTK. We can treat all discrete (ie
non-precision) events as the number of wheel ticks - for wheel mice,
yoff will be "1.0" per tick, while precision wheel mice may report
fractional values. This unifies handling of scroll events by normalizing
all events to "pixels to scroll".
We now report `mouse-scroll-multiplier` wheel or arrow events per wheel
tick (or per accumulated cell height). This means that applications
which subscribe to mouse button events will receive (by default) three
wheel events per wheel tick. For precision scrolls, they will receive
one wheel tick per line of scroll. In my opinion, this provides the best
user experience while also allowing customization of how much a
wheel tick should scroll
Reference: https://github.com/ghostty-org/ghostty/discussions/6677
Upstream is now mostly pure Zig and the build.zig.zon.* files are
generated directly by zon2nix. The JSON file is no longer used as an
intermediate file but is retained for downstream packager usage.
Upstream is now mostly pure Zig and the build.zig.zon.* files are
generated directly by zon2nix. The JSON file is no longer used as an
intermediate file but is retained for downstream packager usage.
Some wheel mice are capable of reporting fractional wheel ticks. These
mice don't necessarily report a corresponding precision scroll start
event, at least in Wayland + GTK. We can treat all discrete (ie
non-precision) events as the number of wheel ticks - for wheel mice,
yoff will be "1.0" per tick, while precision wheel mice may report
fractional values. This unifies handling of scroll events by normalizing
all events to "pixels to scroll".
We now report `mouse-scroll-multiplier` wheel or arrow events per wheel
tick (or per accumulated cell height). This means that applications
which subscribe to mouse button events will receive (by default) three
wheel events per wheel tick. For precision scrolls, they will receive
one wheel tick per line of scroll. In my opinion, this provides the best
user experience while also allowing customization of how much a
wheel tick should scroll
Reference: https://github.com/ghostty-org/ghostty/discussions/6677
This allows `termio.Exec` to track processes spawned via
`FlatpakHostCommand`, finally allowing Ghostty to function as a Flatpak.
Alongside this is a few bug fixes:
* Don't add ghostty to PATH when running in flatpak mode since it's
unreachable.
* Correctly handle exit status returned by Flatpak. Previously this was
not processed and contains extra status bits.
* Use correct type for PID returned by Flatpak.
Fixes#6727
The major change in this commit is to consolidate all the C imports in a
single decl in main.zig. This is required for Zig 0.14. Without it, the
problem in #6727 will happen. I was never able to minimize why this
happens in order to open a Zig bug.
Beyond this, I fixed the build.zig and build.zig.zon to work with Zig
0.14 so that we can test building `pkg/macos` in isolation. There are no
downstream impacting changes in the build.zig files.
This allows `termio.Exec` to track processes spawned via
`FlatpakHostCommand`, finally allowing Ghostty to function as a
Flatpak.
Alongside this is a few bug fixes:
* Don't add ghostty to PATH when running in flatpak mode since it's
unreachable.
* Correctly handle exit status returned by Flatpak. Previously this was
not processed and contains extra status bits.
* Use correct type for PID returned by Flatpak.
Fixes#6727
The major change in this commit is to consolidate all the C imports in
a single decl in main.zig. This is required for Zig 0.14. Without it,
the problem in #6727 will happen. I was never able to minimize why this
happens in order to open a Zig bug.
Beyond this, I fixed the build.zig and build.zig.zon to work with Zig
0.14 so that we can test building `pkg/macos` in isolation. There are no
downstream impacting changes in the build.zig files.
