Windows UI redesign — Viewer inspection/input/feedback epic: five focused jobs #113

Coordination epic — work through the small jobs

This issue groups related work; it is not one implementation job or one all-at-once design approval. Review and complete the linked leaf issues separately. Their questions, narrow scopes and prerequisites govern execution. The older phase-wide material below is reference context.

Screen context

This is a UI proposal, not an implemented screenshot. Implement only the boundary of the leaf job under discussion, not every contextual element visible in the picture.

Coordination status: awaiting job-level discussion. Keep this epic open until its linked jobs have actual implementation/verification evidence. The first discussion is #117, typography only. No automatic next-job work or release.

Visual walkthrough and discussion

Info separates what the file contains from how Q1View displays it. Relevant RAW/video controls appear in their own context. Text input and dialogs keep their keys instead of triggering global shortcuts.

Schematic only: these diagrams explain structure and behavior, not exact pixel geometry, font rendering, or an implemented Windows screenshot.

flowchart TD
  INFO["Optional Info panel"] --> FILE["File<br/>Name · path · dimensions"]
  INFO --> INPUT["Input<br/>Decoded format or relevant RAW settings"]
  INFO --> DISPLAY["Display<br/>Scaling and actual display conversion"]
  INFO --> PIXEL["Pixel<br/>Position and values<br/>Source Y/U/V ≠ Display R/G/B"]
  VIDEO["Video / sequence input"] --> PLAY["Playback and frame timeline"]
  STILL["Still image input"] --> NO_TIME["No unnecessary timeline"]

flowchart TD
  KEY["Key press"] --> EDIT{"Typing, IME, modal, or popup?"}
  EDIT -- "Yes" --> LOCAL["Let that context handle the key"]
  EDIT -- "No" --> FOCUS{"Focused list/control handles it?"}
  FOCUS -- "Yes" --> CONTROL["One local action"]
  FOCUS -- "No" --> GLOBAL["One applicable global command"]

Historical phase-level discussion prompts (reference)

• Are File / Input / Display / Pixel the right sections and priority for your work?

• Should the Pixel information live primarily in Info, with only compact overlays near inspection points?

• Are the proposed confirmations and partial-failure messages understandable and safe?

Reference status: use the focused leaf-job questions above for approval. This phase-wide material is not one implementation job.

Parent and dependencies

Parent: #110. Depends on #111, #112. Complete and verify prerequisites before this stage.

Goal

Expose technical information and relevant controls only when needed, with consistent feedback and keyboard behavior.

Implementation scope

• Implement a default 280 DIP Info panel (260–400) with File / Input / Display / Pixel sections. Unknown data is —; distinguish source Y/U/V and display R/G/B.
• Show RAW interpretation controls only for relevant sources, and playback/frame/timeline controls only for video/sequences. Keep rendering and appearance preferences separate.
• At narrower widths show one supplemental panel at a time; honor the last-used panel and saved preferences. Do not unexpectedly reopen a panel when the window grows.
• Use compact, opaque, readable pixel overlays that avoid the inspected position and do not alter raw samples, captures, or comparison buffers.
• Provide coherent empty/loading/no-preview/failure states; failed paths retain the current folder/image. Avoid indefinite shimmer or made-up progress.
• Keep ordinary Recycle Bin actions neutral. Confirmation names the exact item count/representative files, starts on safe Cancel, and reports partial successes/failures without promising Undo.
• Unify app-drawn menu, status, help, settings, and dialog typography; preserve native OS menus/dialogs and Alt navigation.
• Route modal/text/IME input before global commands; E and other letter shortcuts must not fire while typing. List/graph arrows keep local semantics. Add UIA names/roles/states for custom controls and logical Tab navigation.

Acceptance criteria

• Info values and labels match actual input/display state, including RAW/YUV, Pixel Exact, and current HDR/HLG display policy.
• No per-frame geometry oscillation or inspector-induced image movement outside the established Fit/manual rules.
• Empty/filtered/error/loading/partial-Recycle-Bin states are unambiguous and actionable.
• Text entry, IME composition, dialogs, popup menus, collection focus, help, and global commands receive one appropriate action.
• UIA exposes name/role/value/selection/focus/enabled state; essential meaning is not color-only or hover-only.
• Light/Dark/System/high contrast, reduced motion, DPI and Windows text scaling pass the affected-screen checks.

Execution and completion rules

Windows MFC Viewer/Comparator only; follow the parent specification and existing AGENTS.md. Start a focused branch from current origin/master and keep unrelated changes intact. Reuse existing command IDs and rendering/data paths. Run relevant automated/manual checks plus local CoreRegressionTests and both Windows Release builds for changes affecting shared or release-sensitive code. Record the branch/PR, verification evidence, remaining limitations, and any regression fixes. A mockup or build alone is not completion. Do not tag/publish a release in this implementation step.