# egui-viewer (archived)

**Status**: Archived on 2026-08-02. Not under active development.
**Reason**: Lost the toolkit spike comparison to `iced`. See `../SPIKE_COMPARISON.md` and `../../DECISION.md`.

## Why we didn't pick egui

We tested both `iced-viewer` and `egui-viewer` side-by-side on Arch Linux. Summary of the call:

1. **Runtime behavior**: iced ran smoothly out of the box; egui loaded but exhibited visible issues (rendering / input quirks) that would have required additional debugging time to diagnose and fix before we could even start on real features.
2. **Visual polish**: iced's dark theme (`Theme::Dark`) looked closer to the ristretto+ target aesthetic out of the box. egui's default dark leans blue-grey and required manual panel-fill overrides to look right.
3. **Async story**: iced's `Task::perform` integrates cleanly with the runtime; egui has no built-in async story and we were already spawning `std::thread` + polling `JoinHandle::is_finished()` for the file dialog. That pattern does not scale to a lazy-loaded thumbnail bar.
4. **Declarative state**: iced's `Message` enum makes the state machine explicit. For an app with as much interaction surface as an image viewer (scroll, zoom, pan, context menu, fullscreen, thumbnail clicks, keymap), explicit state transitions are easier to reason about than immediate-mode input polling.

## What egui had going for it (and what we lose)

These were genuine egui strengths that we are giving up by choosing iced:

- **Smaller binary** (15.5 MB vs 23 MB for the spike).
- **`Response::context_menu()`** gives right-click menus for free. In iced we'll roll our own with an overlay layer — more work, but we get full styling control (which we wanted anyway for the gpicview-inspired menu).
- **`ViewportBuilder`** makes fullscreen toggling trivial. In iced 0.13 we'll use the platform's window APIs (likely `winit` directly via iced's `window` subsystem).
- **Immediate-mode layout** is conceptually simpler for tool-heavy UIs.

## What's preserved here

This archived crate contains the original spike source (`Cargo.toml`, `src/main.rs`). The prebuilt release binary was discarded to save disk space — re-run `cargo build --release` if you need it.

## Don't delete this

Keep the archive around for two reasons:

1. **Reference**: If we hit a wall with iced on a specific feature (e.g. context menu ergonomics), the egui spike is a reminder of what the alternative API looked like.
2. **Restart path**: If iced turns out to be the wrong call after the MVP is built, we have a working egui starting point instead of starting from zero.

The spike code is licensed under the same terms as the parent project. See `../../README.md`.