Rendered SVG/image viewer panel (analogous to the Markdown viewer)

[fbartho]

Describe the solution you'd like?

Opening an .svg (or other image) file in Warp currently shows the raw file content — for SVG, that's raw XML text. Warp already has a rendered viewer panel for Markdown files (with a Rendered/Raw toggle), and that Markdown viewer can already display images, including SVGs, inline. Requesting: give SVGs and other common image formats (PNG, JPEG, GIF, WebP) their own rendered image-viewer panel when opened directly, analogous to the Markdown viewer — instead of falling through to a plain-text code editor pane.

Basic expectations for a first version:

• Opening a .svg/.png/.jpg/.gif/.webp file (double-click in the file tree, cat/open in terminal, etc.) opens a rendered image pane instead of raw text/binary garbage.
• Minimal chrome: fit-to-pane by default, maybe a zoom control. Doesn't need to be fancy for v1.
• A Raw/Rendered toggle similar to what the Markdown viewer offers would be a nice-to-have but isn't essential for v1.

Is your feature request related to a problem? Please describe.

I generate SVG charts/dashboards locally (dataviz output, diagrams, etc.) and open them directly in Warp to check them. Right now that just dumps the raw XML into a text pane, which is useless — I have to shell out to open to see the rendered image. This is also the natural companion to Markdown docs that embed images: if I follow a link to the image file itself (rather than viewing it inline in the doc), I'd expect to see it rendered too.

Additional context

Feasibility notes (from reading the open source): I'm not a Warp engineer, so take this as an outside read rather than an authoritative scoping, but from browsing the public repo it looks like most of the pieces already exist:

• File-type → viewer dispatch already has a well-defined seam. OpenableFileType (code file type detection) and FileTarget (which viewer to route to: MarkdownViewer, CodeEditor, external editor, etc.) live in app/src/util/openable_file_type.rs, resolved via resolve_file_target_with_editor_choice. There's already an is_supported_image_file() helper right next to it (covers jpg/jpeg/png/gif/webp/svg) — but nothing currently routes through it; SVG today falls into the generic Text bucket and opens in the code editor.
• The image rendering machinery is already fully built and reused elsewhere. warpui_core::elements::Image (backed by ImageCache/ImageType in crates/warpui_core/src/image_cache.rs) already rasterizes SVGs via usvg/resvg (with a bundled fallback font) as well as PNG/JPEG/WebP/animated GIF via the image crate, with size-aware caching, fit modes (Cover/Contain/Stretch), and animation playback.
• This machinery is already proven for exactly this use case: the Markdown viewer's inline image rendering (crates/editor/src/render/element/image.rs, RenderableImage) is a ~50-line wrapper that just constructs Image::new(asset_source, CacheOption::BySize).contain() and lets the cache/renderer do the work.
• The panel-opening mechanism looks generic, not Markdown-specific. open_file_notebook() (app/src/workspace/view.rs) — which the FileTarget::MarkdownViewer case calls — just builds a FilePane and inserts it into the active pane group via the existing Direction/PanesLayout APIs. Nothing about it appears intrinsically tied to Markdown parsing.

Net read: I didn't find an architectural blocker. It looks more like a composition gap — adding an ImageViewer (or similar) FileTarget variant, wiring is_supported_image_file() into the dispatch logic, and building a thin viewer pane that reuses the existing Image element and pane-opening plumbing the same way the Markdown viewer does. Happy to be corrected if there's context I'm missing from outside the public repo.

Related: #13652 (markdown raw-HTML <img> support). Possibly overlaps with #9729 (image preview in the Code Editor file pane + thumbnail strip) and #12093 (image previews in the code review panel) — those are scoped to inline/thumbnail previews within other panels rather than a standalone rendered viewer for an image file opened directly, but there may be shared plumbing worth coordinating on.

[oz-for-oss]

@fbartho

Here's what I found while triaging this issue:

Thanks for the detailed request. The current code does appear to have image rendering primitives already, but directly opened image files are not routed to a dedicated rendered viewer today, so this looks like a valid feature gap rather than a setup issue.

Maintainer details

I concluded that request to add a standalone rendered image/SVG viewer pane for directly opened image files instead of routing them to raw text, code editor, or system-default handling..

Triage summary

This is an enhancement request for a standalone rendered image/SVG viewer pane when opening image files directly in Warp. The current code supports Markdown/Code/Text file routing but does not define an image-viewer target; app/src/util/openable_file_type.rs treats .svg as text and binary image formats as not openable in Warp, while app/src/notebooks/link.rs special-cases supported images to system-generic handling for links.

Existing rendering primitives appear reusable: crates/warpui_core/src/image_cache.rs decodes/rasterizes SVG, PNG, JPEG, WebP, and GIF, and crates/warpui_core/src/elements/gui/image.rs exposes the Image element that Markdown/image-rendering paths already use. The likely implementation shape is to add an image-specific file target/viewer pane, wire supported image extensions into file-open resolution, and cover local/remote file-tree and link/open entry points consistently.

Reproducibility

High. The report describes a deterministic feature gap rather than an environment-specific failure, and the current routing code supports the described behavior.

Duplicate check

I enumerated open issues and found related but differently scoped requests: #9729 covers Code Editor image preview plus thumbnails, #12093 covers code review image previews, #13652 covers raw-HTML image support in Markdown, and #1693/#3953 focus terminal inline image display. I did not find two or more existing open issues that request the same standalone rendered image-file viewer, so this is not marked duplicate.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[fbartho]

Related: #13658 — stale-image caching in the markdown viewer, filed the same day from the same investigation. An image viewer panel would presumably reuse the same AssetSource/ImageCache pipeline, so the content-version fix proposed there is relevant prior art here too.