Application color palette is unfriendly for various monitors #26
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sorokin.oleg.edu/ARCADIA-Studio#26
Reference in New Issue
Block a user
The colors used in the application sometimes cannot be displayed on some monitors with small color space. Need to change the application palette so every graphical element in it is displayed clearly and sharply
This is a part of #1
Codex-956atf native evidence relevant to this issue: staged Windows source83f53c7 shows very pale unselected scenario activation outlines/fills and message labels on white at100%; they become particularly difficult at66% Fit in1100x700 client size. Selected bars/messages are more legible due teal strokes. This was observed on real bound OA/SA nested-call fixtures during #21 acceptance; screenshots will be included in the portable native archive. The bounded #21 paint-order repair leaves palette unchanged, so it must not be interpreted as closing this contrast issue. No broad palette implementation claim is made.
Codex-956atf/root claims a bounded palette/readability outcome based on the new native witness. Session Codex-956atf; initial scope is source and contrast audit plus materially different candidate palettes/evaluators, isolated from current
d61f1f3build and #21 geometry work. Acceptance will require legible text and distinguishable graphical/control boundaries on ordinary sRGB displays, selection/disabled/focus states recognizable without hue alone, and actual native OA/SA/editor/Inspector checks at default and minimum window sizes. We cannot prove arbitrary defective monitor behavior; we can remove reliance on near-white differences and validate representative degradation/contrast cases. No palette implementation or pass claimed yet.Codex-956atf palette checkpoint: source audit and fresh critique led to a bounded stronger light palette retaining category hues, separate essential boundaries versus decorative dividers, and explicit shared Iced control pairs. Source editor uses a separate medium selection fill plus dark syntax/fallback; ordinary inputs keep their existing surface with a darker shared ink. This is an uncompiled isolated candidate, not accepted display behavior. Fresh review caught a reachable read-only selection case: Iced inputs without an edit callback still select/copy, and the candidate's default Disabled selected value was only2.07:1. Correction is underway; selection/copy will be preserved. Canvas consumers separately add essential outlines and selected state-row borders without geometry/hit changes. Warning-route non-hue discoverability will use a bounded contextual selector proposal; an on-route glyph was rejected for this scope because current measured label/arrow geometry cannot place it safely. Native syntax scanability, focus/disabled states, limited-color/degradation witnesses and min-scale readability remain required. No issue closure or universal-monitor claim.
Codex-956atf /root: reviewed palette foundation, canvas consumers and readonly-selection correction are integrated and normally pushed at
afa74a3059on codex/release1-956atf. Fresh review confirms the readonly adapter preserves actual Iced selection/copy and secure-token restrictions; its mounted test includes enabled-submit → same-cache readonly selection, actual range/glyph paint and blocked edits. Process topology's two missed essential outline sites also now use BOUNDARY (2c6eded). The serialized Windows style::tests gate is compiling against 538 committed inputs (manifest d7dc0bd3b642e50c2796035696fc6da5bb0cbf07e680e15528c49229544c5583); no runtime or monitor acceptance yet.Residual source review found custom chooser/menu keyboard target fills and scroll/containment boundaries bypassing the central palette. I retain this bounded follow-up ownership in an isolated worktree while the current source stays frozen: inset target cues and essential boundary colors only, preserving geometry, keyboard state and actions. A searchable routing-warning selector would additionally require an authoritative canvas/gesture bridge and search support; it is separately unfinished, not part of this color patch. Full combined gates/native inspection remain required; #26 stays open. Linux remains user-deferred.
Codex-956atf /root: all10 palette tests passed on
afa74a3(538 unchanged inputs), including actual WGPU readonly selection/copy and same-cache enabled→readonly rebuild. Exact results, candidate decisions and independent reviews are published at05b613e in harness/release-palette-readability-20260913.md.The bounded custom-overlay correction is integrated at
a357b22: target-row shape cues, enabled chooser/popup boundaries and overflow thumb, with no layout/hit/action changes. Its first tests compiled but each new initial paint assertion failed: context-menu11PASS/1FAIL; chooser13PASS/1FAIL. Actual Iced runtime source shows both tests drew before UserInterface initialized its retained overlay layout, so they observed blank background. Reviewed test-onlye44f075now performs the normal empty-event update before each required draw; thresholds, paint, keyboard and exact-choice assertions are unchanged. Both commits are normally pushed. The corrected gate is compiling against538 frozen inputs; runtime success remains pending. Original failures are preserved locally for the next evidence commit. No full/native/monitor acceptance or issue closure is claimed.