dtourolle/DarkRoom
1
0
Fork 0
Code Issues 39 Pull Requests Actions Packages Projects Releases 20 Wiki Activity

FR-DEV-14 — Hold one key to see the unedited original #3

New Issue
Closed
opened 2026-09-05 16:09:15 +00:00 by dtourolle · 2 comments
dtourolle commented 2026-09-05 16:09:15 +00:00
Owner
Copy Link
Copy Source

Holding one key shall show the unedited original in place; releasing it returns to the edit. The same gesture shall work against a named snapshot.

Why

This is the check that keeps an edit honest, and the one the over-editing literature keeps returning to — the tells are known (halos, smoky highlights, contrast that glows, saturation gone nuclear) and all of them are only visible against the original.

FR-DEV-7 already requires this and its first clause has no implementation. What exists is history navigation (History::go_to), which changes the edit rather than previewing against it — so the photographer must undo, look, and redo. That difference matters most at exactly the moment the answer is "I have gone too far".

Today DarkRoom has exactly one comparison gesture in develop: a mask layer's enabled toggle.

Acceptance

  • Held comparison pushes no history step and does not mark the image modified.
  • Toggle latency meets the same budget as a slider (FR-DSP-3).
  • Available on touch as a press-and-hold, per FR-DEV-3b's modality mapping.
  • Once named snapshots exist, the same gesture compares against a chosen snapshot — closing FR-DEV-7's second clause too.

Deliberately not

A split-screen before/after. Held comparison is cheaper, is what the sources describe photographers actually using, and does not halve the working image on a tablet.

Closes

FR-DEV-7's first clause.

Part of the Develop Ergonomics spec (FR-DEV series proposal), 2026-09-05.

Holding one key shall show the **unedited original** in place; releasing it returns to the edit. The same gesture shall work against a named snapshot. ## Why This is the check that keeps an edit honest, and the one the over-editing literature keeps returning to — the tells are known (halos, smoky highlights, contrast that glows, saturation gone nuclear) and all of them are only visible against the original. **FR-DEV-7 already requires this** and its first clause has no implementation. What exists is history navigation (`History::go_to`), which *changes* the edit rather than previewing against it — so the photographer must undo, look, and redo. That difference matters most at exactly the moment the answer is "I have gone too far". Today DarkRoom has exactly one comparison gesture in develop: a mask layer's `enabled` toggle. ## Acceptance - [ ] Held comparison pushes no history step and does not mark the image modified. - [ ] Toggle latency meets the same budget as a slider (FR-DSP-3). - [ ] Available on touch as a press-and-hold, per FR-DEV-3b's modality mapping. - [ ] Once named snapshots exist, the same gesture compares against a chosen snapshot — closing FR-DEV-7's second clause too. ## Deliberately not A split-screen before/after. Held comparison is cheaper, is what the sources describe photographers actually using, and does not halve the working image on a tablet. ## Closes FR-DEV-7's first clause. --- Part of the Develop Ergonomics spec (FR-DEV series proposal), 2026-09-05.
dtourolle added the developergonomicsuiunmet-requirementsize:S labels 2026-09-05 16:09:15 +00:00
dtourolle commented 2026-09-05 16:09:50 +00:00
Author
Owner
Copy Link
Copy Source

Closes the first clause of #14.
Doubles in value with #8 — comparing against a chosen snapshot rather than only against the original.
Bind in #6.

**Closes the first clause of** #14. **Doubles in value with** #8 — comparing against a chosen snapshot rather than only against the original. **Bind in** #6.
dtourolle commented 2026-09-19 10:19:15 +00:00
Author
Owner
Copy Link
Copy Source

Landed in 2584b9e (2026-09-05): hold backslash to see the unedited original, in app.slint. The requirements audit of 2026-09-19 folds this behaviour under FR-DEV-7 and FR-DEV-16's "holding the original"; the spec defines no FR-DEV-14, and per that audit the spec's numbering wins.

Landed in 2584b9e (2026-09-05): hold backslash to see the unedited original, in app.slint. The requirements audit of 2026-09-19 folds this behaviour under FR-DEV-7 and FR-DEV-16's "holding the original"; the spec defines no FR-DEV-14, and per that audit the spec's numbering wins.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
a11y
Accessibility
 android
apps/darkroom-android and the platform contract
 blocked
Cannot start until something else lands
 catalog
core/dr-catalog and the data model
 culling
Selection, comparison and the culling surfaces
 decision
Needs a decision recorded, not code
 develop
The develop view and its pipeline
 docs
An edit to the register of record
 ergonomics
How the work feels to do, not what it computes
 gpu
core/dr-gpu and the render path
 i18n
Localisation
 linux
Desktop packaging, portals and distribution
 masks
Local adjustments and selection
 performance
Budgets, benchmarks and frame timing
 pipeline
core/dr-pipeline
 plugins
The plugin host and the declarative format
 post-v1
Specified as the design of record; outside the v1 count
 size:L
A subsystem, not a feature
 size:M
Days
 size:S
Hours to a day
 spike
A validation spike from requirements §9
 sync
dr-sync and the Nextcloud backends
 ui
ui/dr-ui
 unmet-requirement
An existing requirement that is specified but not built
No labels develop ergonomics size:S ui unmet-requirement
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
dtourolle (Duncan Tourolle)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dtourolle/DarkRoom#3