From 98cc1c6d11104cc4981e429b14df58dd68fe9ba9 Mon Sep 17 00:00:00 2001 From: Kat <65649991+00-kat@users.noreply.github.com> Date: Mon, 16 Feb 2026 22:53:31 +1100 Subject: [PATCH] Move docs on developing Ghostty out of CONTRIBUTING.md, attempt two. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Follow-up to #8445, after a messed up rebase in #8339 brought it back alongside an extra section. All text removed from CONTRIBUTING.md was identical to the version present in HACKING.md (according to a textual diff), excluding the “Developer Guide” heading, the callout under it, and the “Nix VM Integration Tests” section introduced in #8339. --- CONTRIBUTING.md | 263 ------------------------------------------------ HACKING.md | 57 +++++++++++ 2 files changed, 57 insertions(+), 263 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 989990ce8..9633029c5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -191,266 +191,3 @@ pull request will be accepted with a high degree of certainty. > **Pull requests are NOT a place to discuss feature design.** Please do > not open a WIP pull request to discuss a feature. Instead, use a discussion > and link to your branch. - -# Developer Guide - -> [!NOTE] -> -> **The remainder of this file is dedicated to developers actively -> working on Ghostty.** If you're a user reporting an issue, you can -> ignore the rest of this document. - -## Including and Updating Translations - -See the [Contributor's Guide](po/README_CONTRIBUTORS.md) for more details. - -## Checking for Memory Leaks - -While Zig does an amazing job of finding and preventing memory leaks, -Ghostty uses many third-party libraries that are written in C. Improper usage -of those libraries or bugs in those libraries can cause memory leaks that -Zig cannot detect by itself. - -### On Linux - -On Linux the recommended tool to check for memory leaks is Valgrind. The -recommended way to run Valgrind is via `zig build`: - -```sh -zig build run-valgrind -``` - -This builds a Ghostty executable with Valgrind support and runs Valgrind -with the proper flags to ensure we're suppressing known false positives. - -You can combine the same build args with `run-valgrind` that you can with -`run`, such as specifying additional configurations after a trailing `--`. - -## Input Stack Testing - -The input stack is the part of the codebase that starts with a -key event and ends with text encoding being sent to the pty (it -does not include _rendering_ the text, which is part of the -font or rendering stack). - -If you modify any part of the input stack, you must manually verify -all the following input cases work properly. We unfortunately do -not automate this in any way, but if we can do that one day that'd -save a LOT of grief and time. - -Note: this list may not be exhaustive, I'm still working on it. - -### Linux IME - -IME (Input Method Editors) are a common source of bugs in the input stack, -especially on Linux since there are multiple different IME systems -interacting with different windowing systems and application frameworks -all written by different organizations. - -The following matrix should be tested to ensure that all IME input works -properly: - -1. Wayland, X11 -2. ibus, fcitx, none -3. Dead key input (e.g. Spanish), CJK (e.g. Japanese), Emoji, Unicode Hex -4. ibus versions: 1.5.29, 1.5.30, 1.5.31 (each exhibit slightly different behaviors) - -> [!NOTE] -> -> This is a **work in progress**. I'm still working on this list and it -> is not complete. As I find more test cases, I will add them here. - -#### Dead Key Input - -Set your keyboard layout to "Spanish" (or another layout that uses dead keys). - -1. Launch Ghostty -2. Press `'` -3. Press `a` -4. Verify that `á` is displayed - -Note that the dead key may or may not show a preedit state visually. -For ibus and fcitx it does but for the "none" case it does not. Importantly, -the text should be correct when it is sent to the pty. - -We should also test canceling dead key input: - -1. Launch Ghostty -2. Press `'` -3. Press escape -4. Press `a` -5. Verify that `a` is displayed (no diacritic) - -#### CJK Input - -Configure fcitx or ibus with a keyboard layout like Japanese or Mozc. The -exact layout doesn't matter. - -1. Launch Ghostty -2. Press `Ctrl+Shift` to switch to "Hiragana" -3. On a US physical layout, type: `konn`, you should see `こん` in preedit. -4. Press `Enter` -5. Verify that `こん` is displayed in the terminal. - -We should also test switching input methods while preedit is active, which -should commit the text: - -1. Launch Ghostty -2. Press `Ctrl+Shift` to switch to "Hiragana" -3. On a US physical layout, type: `konn`, you should see `こん` in preedit. -4. Press `Ctrl+Shift` to switch to another layout (any) -5. Verify that `こん` is displayed in the terminal as committed text. - -## Nix Virtual Machines - -Several Nix virtual machine definitions are provided by the project for testing -and developing Ghostty against multiple different Linux desktop environments. - -Running these requires a working Nix installation, either Nix on your -favorite Linux distribution, NixOS, or macOS with nix-darwin installed. Further -requirements for macOS are detailed below. - -VMs should only be run on your local desktop and then powered off when not in -use, which will discard any changes to the VM. - -The VM definitions provide minimal software "out of the box" but additional -software can be installed by using standard Nix mechanisms like `nix run nixpkgs#`. - -### Linux - -1. Check out the Ghostty source and change to the directory. -2. Run `nix run .#`. `` can be any of the VMs defined in the - `nix/vm` directory (without the `.nix` suffix) excluding any file prefixed - with `common` or `create`. -3. The VM will build and then launch. Depending on the speed of your system, this - can take a while, but eventually you should get a new VM window. -4. The Ghostty source directory should be mounted to `/tmp/shared` in the VM. Depending - on what UID and GID of the user that you launched the VM as, `/tmp/shared` _may_ be - writable by the VM user, so be careful! - -### macOS - -1. To run the VMs on macOS you will need to enable the Linux builder in your `nix-darwin` - config. This _should_ be as simple as adding `nix.linux-builder.enable=true` to your - configuration and then rebuilding. See [this](https://nixcademy.com/posts/macos-linux-builder/) - blog post for more information about the Linux builder and how to tune the performance. -2. Once the Linux builder has been enabled, you should be able to follow the Linux instructions - above to launch a VM. - -### Custom VMs - -To easily create a custom VM without modifying the Ghostty source, create a new -directory, then create a file called `flake.nix` with the following text in the -new directory. - -``` -{ - inputs = { - nixpkgs.url = "nixpkgs/nixpkgs-unstable"; - ghostty.url = "github:ghostty-org/ghostty"; - }; - outputs = { - nixpkgs, - ghostty, - ... - }: { - nixosConfigurations.custom-vm = ghostty.create-gnome-vm { - nixpkgs = nixpkgs; - system = "x86_64-linux"; - overlay = ghostty.overlays.releasefast; - # module = ./configuration.nix # also works - module = {pkgs, ...}: { - environment.systemPackages = [ - pkgs.btop - ]; - }; - }; - }; -} -``` - -The custom VM can then be run with a command like this: - -``` -nix run .#nixosConfigurations.custom-vm.config.system.build.vm -``` - -A file named `ghostty.qcow2` will be created that is used to persist any changes -made in the VM. To "reset" the VM to default delete the file and it will be -recreated the next time you run the VM. - -### Contributing new VM definitions - -#### VM Acceptance Criteria - -We welcome the contribution of new VM definitions, as long as they meet the following criteria: - -1. They should be different enough from existing VM definitions that they represent a distinct - user (and developer) experience. -2. There's a significant Ghostty user population that uses a similar environment. -3. The VMs can be built using only packages from the current stable NixOS release. - -#### VM Definition Criteria - -1. VMs should be as minimal as possible so that they build and launch quickly. - Additional software can be added at runtime with a command like `nix run nixpkgs#`. -2. VMs should not expose any services to the network, or run any remote access - software like SSH daemons, VNC or RDP. -3. VMs should auto-login using the "ghostty" user. - -## Nix VM Integration Tests - -Several Nix VM tests are provided by the project for testing Ghostty in a "live" -environment rather than just unit tests. - -Running these requires a working Nix installation, either Nix on your -favorite Linux distribution, NixOS, or macOS with nix-darwin installed. Further -requirements for macOS are detailed below. - -### Linux - -1. Check out the Ghostty source and change to the directory. -2. Run `nix run .#checks...driver`. `` should be - `x86_64-linux` or `aarch64-linux` (even on macOS, this launches a Linux - VM, not a macOS one). `` should be one of the tests defined in - `nix/tests.nix`. The test will build and then launch. Depending on the speed - of your system, this can take a while. Eventually though the test should - complete. Hopefully successfully, but if not error messages should be printed - out that can be used to diagnose the issue. -3. To run _all_ of the tests, run `nix flake check`. - -### macOS - -1. To run the VMs on macOS you will need to enable the Linux builder in your `nix-darwin` - config. This _should_ be as simple as adding `nix.linux-builder.enable=true` to your - configuration and then rebuilding. See [this](https://nixcademy.com/posts/macos-linux-builder/) - blog post for more information about the Linux builder and how to tune the performance. -2. Once the Linux builder has been enabled, you should be able to follow the Linux instructions - above to launch a test. - -### Interactively Running Test VMs - -To run a test interactively, run `nix run -.#check...driverInteractive`. This will load a Python console -that can be used to manage the test VMs. In this console run `start_all()` to -start the VM(s). The VMs should boot up and a window should appear showing the -VM's console. - -For more information about the Nix test console, see [the NixOS manual](https://nixos.org/manual/nixos/stable/index.html#sec-call-nixos-test-outside-nixos) - -### SSH Access to Test VMs - -Some test VMs are configured to allow outside SSH access for debugging. To -access the VM, use a command like the following: - -``` -ssh -o StrictHostKeyChecking=accept-new -o UserKnownHostsFile=/dev/null -p 2222 root@192.168.122.1 -ssh -o StrictHostKeyChecking=accept-new -o UserKnownHostsFile=/dev/null -p 2222 ghostty@192.168.122.1 -``` - -The SSH options are important because the SSH host keys will be regenerated -every time the test is started. Without them, your personal SSH known hosts file -will become difficult to manage. The port that is needed to access the VM may -change depending on the test. - -None of the users in the VM have passwords so do not expose these VMs to the Internet. diff --git a/HACKING.md b/HACKING.md index 0abb3a2d8..921ed71ff 100644 --- a/HACKING.md +++ b/HACKING.md @@ -403,3 +403,60 @@ We welcome the contribution of new VM definitions, as long as they meet the foll 2. VMs should not expose any services to the network, or run any remote access software like SSH daemons, VNC or RDP. 3. VMs should auto-login using the "ghostty" user. + +## Nix VM Integration Tests + +Several Nix VM tests are provided by the project for testing Ghostty in a "live" +environment rather than just unit tests. + +Running these requires a working Nix installation, either Nix on your +favorite Linux distribution, NixOS, or macOS with nix-darwin installed. Further +requirements for macOS are detailed below. + +### Linux + +1. Check out the Ghostty source and change to the directory. +2. Run `nix run .#checks...driver`. `` should be + `x86_64-linux` or `aarch64-linux` (even on macOS, this launches a Linux + VM, not a macOS one). `` should be one of the tests defined in + `nix/tests.nix`. The test will build and then launch. Depending on the speed + of your system, this can take a while. Eventually though the test should + complete. Hopefully successfully, but if not error messages should be printed + out that can be used to diagnose the issue. +3. To run _all_ of the tests, run `nix flake check`. + +### macOS + +1. To run the VMs on macOS you will need to enable the Linux builder in your `nix-darwin` + config. This _should_ be as simple as adding `nix.linux-builder.enable=true` to your + configuration and then rebuilding. See [this](https://nixcademy.com/posts/macos-linux-builder/) + blog post for more information about the Linux builder and how to tune the performance. +2. Once the Linux builder has been enabled, you should be able to follow the Linux instructions + above to launch a test. + +### Interactively Running Test VMs + +To run a test interactively, run `nix run +.#check...driverInteractive`. This will load a Python console +that can be used to manage the test VMs. In this console run `start_all()` to +start the VM(s). The VMs should boot up and a window should appear showing the +VM's console. + +For more information about the Nix test console, see [the NixOS manual](https://nixos.org/manual/nixos/stable/index.html#sec-call-nixos-test-outside-nixos) + +### SSH Access to Test VMs + +Some test VMs are configured to allow outside SSH access for debugging. To +access the VM, use a command like the following: + +``` +ssh -o StrictHostKeyChecking=accept-new -o UserKnownHostsFile=/dev/null -p 2222 root@192.168.122.1 +ssh -o StrictHostKeyChecking=accept-new -o UserKnownHostsFile=/dev/null -p 2222 ghostty@192.168.122.1 +``` + +The SSH options are important because the SSH host keys will be regenerated +every time the test is started. Without them, your personal SSH known hosts file +will become difficult to manage. The port that is needed to access the VM may +change depending on the test. + +None of the users in the VM have passwords so do not expose these VMs to the Internet.