Now when the agent reads images (which the tool now explicitly
advertises to agents that it is capable of; previously the tool said it
could only read text even though it can actually read images), we see
them in the thread, and also they are auto-expanded by default so you
can see them when scrolling through:
<img width="725" height="1019" alt="Screenshot 2026-01-06 at 2 57 11 PM"
src="https://github.com/user-attachments/assets/5c908bad-48f2-46c2-afaa-7f189a178e05"
/>
This also adds a visual regression test that verifies images render
correctly in the agent thread view.
Unlike our previous visual tests, this one only renders the agent panel,
not the entire Zed window.
The "screenshot" it generates (rendered to a Metal texture) is from
completely mocked/simulated data structures, and looks like this:
<img width="546" height="984" alt="Screenshot 2026-01-06 at 2 54 41 PM"
src="https://github.com/user-attachments/assets/89a0921f-59e9-4dfe-94b2-4c3b625a851b"
/>
## Changes
- **New visual test**: `agent_thread_with_image` renders an
`AcpThreadView` containing a tool call with image content (the Zed app
icon)
- **Test infrastructure**: Added `StubAgentServer` helper and required
feature flags for visual testing
- **Test-support API**: Added `expand_tool_call()` method to
`AcpThreadView` to allow expanding tool calls for visual testing
- **Baseline screenshot**: Included baseline image showing the Zed logo
rendered in a tool call output
## How to run
```bash
# Run the visual tests
cargo run -p zed --bin visual_test_runner --features visual-tests
# Update baselines if UI intentionally changed
UPDATE_BASELINE=1 cargo run -p zed --bin visual_test_runner --features visual-tests
```
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Amp <amp@ampcode.com>
This fixes the auto-update failure by ensuring cargo-bundle picks 'zed'
as the first binary.
**Problem:** `cargo metadata` returns binaries alphabetically, so
`visual_test_runner` was coming before `zed`. When cargo-bundle looks
for the first binary to bundle (without `--bin`), it was picking
`visual_test_runner` - which doesn't exist in release builds because it
requires the `visual-tests` feature.
The previous fix (#46163) added `--bin zed` to explicitly select the
binary, but this caused cargo-bundle to use the binary name ('zed')
instead of the bundle metadata name ('Zed Nightly'), breaking
auto-updates.
**Fix:** Rename the binary to `zed_visual_test_runner` so it comes after
`zed` alphabetically. This restores the original bundle script behavior
that has worked for years.
Also reverts the `--bin zed` workaround from #46163.
Release Notes:
- N/A
## Screenshot testing
Adds visual testing infrastructure for GPUI that captures screenshots by
rendering directly to Metal textures. The
The screenshots end up in `target/visual_tests/` and look like this:
<img width="2560" height="1600" alt="workspace_with_editor2"
src="https://github.com/user-attachments/assets/54112343-4af1-4347-9bab-f099de97dd29"
/>
<img width="2560" height="1600" alt="project_panel2"
src="https://github.com/user-attachments/assets/0cd54b61-dace-4398-a28e-0b4d7c2968f6"
/>
### Key Features
- **Direct texture capture**: Screenshots are captured by rendering the
scene to a Metal texture and reading pixels directly from GPU memory,
rather than using ScreenCaptureKit
- **No visibility requirements**: Windows don't need to be visible on
screen since we read directly from the render pipeline
- **Deterministic output**: Captures exactly what GPUI renders, not what
the OS compositor displays
- **No permissions needed**: Doesn't require Screen Recording permission
like ScreenCaptureKit would
### Running the Visual Tests
```bash
# Run visual tests (compares against baselines)
cargo run -p zed --bin visual_test_runner --features visual-tests
# Update baseline images (when UI intentionally changes)
UPDATE_BASELINE=1 cargo run -p zed --bin visual_test_runner --features visual-tests
# View the captured screenshots
open target/visual_tests/
```
### Implementation
- `Window::render_to_image()` - Renders the current scene to a texture
and returns an `RgbaImage`
- `MetalRenderer::render_to_image()` - Core implementation that renders
to a non-framebuffer-only texture
- `VisualTestAppContext` - Test context that uses real macOS platform
rendering
- `VisualTestAppContext::capture_screenshot()` - Synchronous screenshot
capture using direct texture rendering
### Usage
```rust
let mut cx = VisualTestAppContext::new();
let window = cx.open_window(...)?;
let screenshot: RgbaImage = cx.capture_screenshot(window.into())?;
```
Release Notes:
- N/A
---------
Co-authored-by: Amp <amp@ampcode.com>
@ConradIrwin No longer needed the issue appears to be fully resolved
after moving to MacOS Tahoe as the latest instead of only in dev beta
Release Notes:
- N/A
- I believe this is caused by metal not being found due to it being on
the XcodeBeta path, not sure if there's a better fix for this but it'll
work until 26 is the latest release
Release Notes:
- N/A
Simplify docs for mac/linux/windows by consolidating the backend
dependencies (collaboration) docs into local-collaboration.md. Most
users building zed will not need to do this -- streamline them into
getting setup to build the zed client app first.
Release Notes:
- N/A
Updating macOS development readme with some gotchas that I ran into
while getting setup.
- Linked to collab readme because that contained the steps to setup the
postgres database so integration tests pass
- Added section under troubleshooting. Recommending `cargo-nextest`
since the CI uses it and it got me past the failures I was seeing.
Release Notes:
- N/A
---------
Co-authored-by: KyleBarton <kjbarton4@gmail.com>
Some changes just so the build docs for the different os matches each
other :)
macos:
- moved `rust wasm toolchain install` up under `rust install` (match
windows docs)
- add instructions to update rust if already installed (match windows
and linux docs)
windows:
- add `(required by a dependency)` to cmake install (match macos docs)
Release Notes:
- N/A
- Add `script/build-docker`
- Add `script/install-cmake`
- Add `script/install-mold`
- Improve `script/linux`
- Add missing dependencies: `jq`, `git`, `tar`, `gzip` as required.
- Add check for mold
- Fix Redhat 8.x derivatives (RHEL, Centos, Almalinux, Rocky, Oracle, Amazon)
- Fix perl libs to be Fedora only
- Install the best `libstdc++` available on apt distros
- ArchLinux: run `pacman -Syu` to update repos before installing.
- Should work on Raspbian (untested)
This make it possible to test builds on other distros using docker:
```
./script/build-docker amazonlinux:2023
```
### Title
Update macOS Development Documentation with Dispatch.h Error Solution
### Description
This PR updates the macOS development documentation to include a
solution for the `dispatch/dispatch.h` file not found error. This error
is encountered during local development when using the `cargo run`
command. The documentation now includes steps to ensure the Xcode
command line tools are properly installed and set, and instructions to
set the `BINDGEN_EXTRA_CLANG_ARGS` environment variable.
### Changes
- Added troubleshooting section for `dispatch/dispatch.h` error in
`development/macos.md`.
### Related Issues
- Closes [#11963](https://github.com/zed-industries/zed/issues/11963)
### Testing Instructions
1. Follow the steps in the updated `development/macos.md` to configure
your environment.
2. Run `cargo clean` and `cargo run` to ensure the build completes
successfully.
Release Notes:
- N/A
This PR removes the references to initializing Git submodules as part of
building Zed.
These are no longer needed, as our only submodule was removed in #11672.
Release Notes:
- N/A
morgankrey