#85 - tui: image renderer integration — thread ImageRenderer through AppCtx - charles/loom

claude-desktop commented

2026-04-12 13:23:12 +00:00

Collaborator

User Story

As a loom-tui user, I want the auto-detected image renderer to be available to all screens via AppCtx, so that gallery thumbnails, model cards, preview panes, and entity portraits actually display images in the terminal.

Context

The image/ subsystem (Kitty, Sixel, Chafa, half-block) was built in Phase 2 (#12–#15) with an ImageRenderer trait and auto-detection. But the renderer is not threaded through AppCtx — no screen can actually call renderer.render(). This ticket connects the rendering pipeline.

Acceptance Criteria

AppCtx Integration

AppCtx holds an Arc<dyn ImageRenderer> populated at startup by the auto-detect logic
Config override (tui.toml → image_protocol) is respected if set to a specific backend
Screens access the renderer via ctx.image_renderer()

Async Pipeline

Image decode/resize runs in a background task (not blocking the event loop)
Results are sent to the main loop via mpsc channel
Render cache keyed by (path, width, height) hash avoids redundant transmissions

Cleanup

On screen change or resize, stale image placements are deleted (Kitty a=d,d=A)
On app exit, all image state is cleaned up

Tests

Unit test: cache key generation and eviction
Unit test: fallback to half-block when no external tool is available

Out of Scope

Per-screen image display logic (each screen's integration ticket handles its own rendering calls)

References

Spec §2.2 (Image Rendering Subsystem)
Existing code: src/image/mod.rs, kitty.rs, sixel.rs, chafa.rs, detect.rs
Tracking issue: #47

## User Story As a **loom-tui user**, I want the auto-detected image renderer to be available to all screens via `AppCtx`, so that gallery thumbnails, model cards, preview panes, and entity portraits actually display images in the terminal. ## Context The `image/` subsystem (Kitty, Sixel, Chafa, half-block) was built in Phase 2 (#12–#15) with an `ImageRenderer` trait and auto-detection. But the renderer is not threaded through `AppCtx` — no screen can actually call `renderer.render()`. This ticket connects the rendering pipeline. ## Acceptance Criteria ### AppCtx Integration - [ ] `AppCtx` holds an `Arc<dyn ImageRenderer>` populated at startup by the auto-detect logic - [ ] Config override (`tui.toml` → `image_protocol`) is respected if set to a specific backend - [ ] Screens access the renderer via `ctx.image_renderer()` ### Async Pipeline - [ ] Image decode/resize runs in a background task (not blocking the event loop) - [ ] Results are sent to the main loop via `mpsc` channel - [ ] Render cache keyed by `(path, width, height)` hash avoids redundant transmissions ### Cleanup - [ ] On screen change or resize, stale image placements are deleted (Kitty `a=d,d=A`) - [ ] On app exit, all image state is cleaned up ### Tests - [ ] Unit test: cache key generation and eviction - [ ] Unit test: fallback to half-block when no external tool is available ## Out of Scope - Per-screen image display logic (each screen's integration ticket handles its own rendering calls) ## References - Spec §2.2 (Image Rendering Subsystem) - Existing code: `src/image/mod.rs`, `kitty.rs`, `sixel.rs`, `chafa.rs`, `detect.rs` - Tracking issue: #47

claude-desktop added this to the loom-tui v0.1.0 milestone

2026-04-12 13:23:12 +00:00

claude-desktop added the

type:user-story

area:image

labels

2026-04-12 13:23:12 +00:00

claude-desktop referenced this issue

2026-04-12 13:25:47 +00:00

tui: tracking — loom-tui v0.1.0 roadmap & implementation order #47