Let a press on the photograph reach the tool that was armed for it

The brush did nothing, and neither did three other things nobody had tried
lately: clicking a subject on the photograph to select it, placing a repair,
and sampling a neutral. All four are TouchAreas over the canvas, and all four
sat behind the pan/zoom area, which is full-canvas and enabled for everything
but a crop. It took every press in the viewport and they were never offered
one.

Slint hit-tests siblings front-to-back (`send_mouse_event_to_item` visits
children `TraversalOrder::FrontToBack`), a TouchArea answers `GrabMouse` on any
press it is enabled for, and the first grab aborts the traversal. Front means
*last declared*. Each of the four carried a comment saying it sat "above the
pan/zoom area so a click reaches it first" — true of the order they were
written in, and backwards.

Nothing about the geometry decides this, so nothing about the geometry could
have fixed it. The pan area is declared first now, as the backstop it always
meant to be, and the rule it leaves behind is that the general case goes above
the specific ones. `GradientHandles` is the other end of that rule and is why
dragging a handle has worked all along while everything between it and the pan
area did not.

The order is asserted in a test, because this is a fault that compiles, passes
every other test, and silently removes four tools at once.
This commit is contained in:
2026-09-10 20:56:10 +02:00
parent 76ad667fd6
commit 5d175cc668
5 changed files with 228 additions and 145 deletions
+18 -18
View File
@@ -27,15 +27,6 @@ Anchored on the fingers' midpoint, and on the pointer, so the gesture reads as m
<sub>`ui/dr-ui/ui/app.slint:1941`</sub>
### Paint a mask by hand
- **Touch** — Choose Paint or Erase, then drag on the photograph
- **Pointer** — Choose Paint or Erase, then drag
A model's mask stops inside a shoulder and leaks into the hair, and no single edge control fixes two errors that go opposite ways. The whole stroke is one step in the history, so taking a mark back costs one press however long it took to make.
<sub>`ui/dr-ui/ui/app.slint:2014`</sub>
### Move a magnified photograph about
- **Touch** — Drag it
@@ -43,7 +34,16 @@ A model's mask stops inside a shoulder and leaks into the hair, and no single ed
Only once there is something outside the viewport to reach, which is why the cursor becomes a hand exactly then. The view is clamped to the frame: panning past the edge would show undefined area beside the photograph, and that reads as a rendering fault rather than as the end of the picture.
<sub>`ui/dr-ui/ui/app.slint:2147`</sub>
<sub>`ui/dr-ui/ui/app.slint:2032`</sub>
### Paint a mask by hand
- **Touch** — Choose Paint or Erase, then drag on the photograph
- **Pointer** — Choose Paint or Erase, then drag
A model's mask stops inside a shoulder and leaks into the hair, and no single edge control fixes two errors that go opposite ways. The whole stroke is one step in the history, so taking a mark back costs one press however long it took to make.
<sub>`ui/dr-ui/ui/app.slint:2119`</sub>
### Take back the last change
@@ -53,7 +53,7 @@ Only once there is something outside the viewport to reach, which is why the cur
A whole drag is one step, so undo takes back a decision rather than a frame of a gesture. The list is there because arriving six steps back costs what arriving from one does.
<sub>`ui/dr-ui/ui/app.slint:2314`</sub>
<sub>`ui/dr-ui/ui/app.slint:2340`</sub>
### Do it again after taking it back
@@ -61,7 +61,7 @@ A whole drag is one step, so undo takes back a decision rather than a frame of a
- **Pointer** — Click it, or press Redo in the History header
- **Keyboard** — Ctrl+Shift+Z
<sub>`ui/dr-ui/ui/app.slint:2327`</sub>
<sub>`ui/dr-ui/ui/app.slint:2353`</sub>
### Copy the settings from this photograph
@@ -71,7 +71,7 @@ A whole drag is one step, so undo takes back a decision rather than a frame of a
The panel is the copy that has to work: a tablet has no modifier key to hold and no menu bar to hang the action from. The shortcut is an accelerator for a control that is on screen either way.
<sub>`ui/dr-ui/ui/app.slint:2360`</sub>
<sub>`ui/dr-ui/ui/app.slint:2386`</sub>
### Paste the settings onto this photograph
@@ -81,7 +81,7 @@ The panel is the copy that has to work: a tablet has no modifier key to hold and
The button names what would be pasted — "3 adjustments", and whether the crop is coming with it — which the shortcut cannot say. Both paste the same scope.
<sub>`ui/dr-ui/ui/app.slint:2372`</sub>
<sub>`ui/dr-ui/ui/app.slint:2398`</sub>
### Change which group of adjustments is on screen
@@ -91,7 +91,7 @@ The button names what would be pasted — "3 adjustments", and whether the crop
The groups are whatever the operation set declares itself to be about, so there are as many as the pipeline has and no key can be assigned to one of them by name. Stepping is the binding that survives a node being added.
<sub>`ui/dr-ui/ui/app.slint:2400`</sub>
<sub>`ui/dr-ui/ui/app.slint:2426`</sub>
### Look at the photograph at 1:1
@@ -101,7 +101,7 @@ The groups are whatever the operation set declares itself to be about, so there
Noise reduction and capture sharpening are judgements about single pixels, and a fitted view averages several of the file's into each one on screen — so the frame looks softer than it is and the correction goes too far. The point and the magnification survive opening the next photograph, which is what makes checking the same eye across forty portraits forty keystrokes rather than forty pans.
<sub>`ui/dr-ui/ui/app.slint:2435`</sub>
<sub>`ui/dr-ui/ui/app.slint:2461`</sub>
### Move to the next or previous photograph
@@ -111,7 +111,7 @@ Noise reduction and capture sharpening are judgements about single pixels, and a
The edit on screen is saved on the way out, so stepping through a folder is as much a departure as going back to the grid and loses nothing.
<sub>`ui/dr-ui/ui/app.slint:2465`</sub>
<sub>`ui/dr-ui/ui/app.slint:2491`</sub>
### See the photograph before you edited it
@@ -121,7 +121,7 @@ The edit on screen is saved on the way out, so stepping through a folder is as m
Held rather than toggled, and no split screen: a split halves the working image on the tablet the column was sized for, and the comparison photographers describe making is a flick back and forth. It takes no history step, so checking whether a frame is overcooked costs nothing to undo afterwards.
<sub>`ui/dr-ui/ui/app.slint:2589`</sub>
<sub>`ui/dr-ui/ui/app.slint:2615`</sub>
### Put one control back to its default
+36 -36
View File
File diff suppressed because one or more lines are too long
+7 -7
View File
@@ -36,13 +36,6 @@ pub const GESTURES: &[Gesture] = &[
pointer: "The scroll wheel over it",
keys: "",
},
Gesture {
title: "Paint a mask by hand",
section: "Develop",
touch: "Choose Paint or Erase, then drag on the photograph",
pointer: "Choose Paint or Erase, then drag",
keys: "",
},
Gesture {
title: "Move a magnified photograph about",
section: "Develop",
@@ -50,6 +43,13 @@ pub const GESTURES: &[Gesture] = &[
pointer: "Drag it",
keys: "",
},
Gesture {
title: "Paint a mask by hand",
section: "Develop",
touch: "Choose Paint or Erase, then drag on the photograph",
pointer: "Choose Paint or Erase, then drag",
keys: "",
},
Gesture {
title: "Take back the last change",
section: "Develop",
+57
View File
@@ -1602,3 +1602,60 @@ mod tests {
);
}
}
/// TRACES: FR-DEV-19b | FR-DEV-19c
/// The order the canvas handlers are declared in, which decides which of them
/// receives a press.
///
/// Not a unit test of anything this file does, and here rather than nowhere
/// because there is nowhere better: it guards a fault that compiles, passes
/// every other test, and takes four separate tools out of the application at
/// once.
///
/// Slint hit-tests siblings front-to-back and a `TouchArea` grabs the first
/// press it is offered, so **the last handler declared is the one that wins**.
/// The full-canvas pan/zoom area must therefore come *first*, and `app.slint`
/// had it last — with each of the four handlers behind it carrying a comment
/// claiming it sat "above the pan/zoom area" because it was written earlier in
/// the file.
#[cfg(test)]
mod canvas_order {
/// Where each canvas handler is declared, by byte offset.
fn at(needle: &str) -> usize {
let source = include_str!("../ui/app.slint");
source
.find(needle)
.unwrap_or_else(|| panic!("app.slint no longer contains `{needle}`"))
}
#[test]
fn the_pan_backstop_is_declared_before_every_tool_it_would_swallow() {
let pan = at("--- the pan/zoom backstop ---");
for tool in [
"pick := TouchArea",
"paint := TouchArea",
"Develop.repairing && root.total > 0",
"root.sampling && root.total > 0",
] {
assert!(
pan < at(tool),
"`{tool}` is declared before the pan/zoom area, so the pan area \
is in front of it and will take every press it was meant to get"
);
}
}
/// The other end of the same rule: a handle drawn on the photograph has to
/// beat the tool armed over it, or a gradient cannot be moved while one is.
#[test]
fn the_gradient_handles_are_declared_last() {
let handles = at("GradientHandles {");
for behind in ["pick := TouchArea", "paint := TouchArea"] {
assert!(
handles > at(behind),
"`{behind}` is declared after GradientHandles and would swallow \
a press meant for a handle"
);
}
}
}
+110 -84
View File
@@ -1986,11 +1986,116 @@ in property <bool> panel-visible: true;
cancelled => { self.last-scale = 1.0; }
}
// Region picking, above the pan/zoom area so a click
// reaches it first. A separate area rather than a branch
// inside the one below: panning wants press-drag-release
// and picking wants a click, and interleaving the two in
// one handler is how a drag ends up selecting a region the
// --- the pan/zoom backstop ---------------------------------
//
// **Declared first among the canvas handlers, because in
// Slint that puts it last in line for a press.**
//
// Slint hit-tests siblings `FrontToBack`
// (`i-slint-core`'s `send_mouse_event_to_item`), a
// `TouchArea` answers `GrabMouse` on any press it is
// enabled for, and the first grab aborts the traversal.
// Front means *last declared*. So this — full-canvas, and
// enabled for everything but a crop — took every press in
// the viewport, and the four handlers below it never
// received one: painting a mask, clicking a subject on the
// photograph, placing a repair and sampling a neutral were
// all dead, each of them carrying a comment claiming it sat
// "above the pan/zoom area" because it was written first.
//
// Nothing about the geometry says which wins, so nothing
// about the geometry can be adjusted to fix it. The order
// is the fix, and the rule to keep is: **the general case
// goes at the top of the file and the specific ones after
// it.** `GradientHandles` further down is the other end of
// the same rule, and is why dragging a handle has always
// worked while everything between it and here did not.
if root.total > 0 && root.load-error == "": TouchArea {
x: 0; y: 0;
width: 100%;
height: 100%;
// A pan is only meaningful once there is something outside
// the viewport to reach.
mouse-cursor: root.zoomed ? MouseCursor.grab : MouseCursor.default;
enabled: !Develop.cropping;
property <length> last-x;
property <length> last-y;
pointer-event(ev) => {
if (ev.kind == PointerEventKind.down) {
self.last-x = self.mouse-x;
self.last-y = self.mouse-y;
}
}
// GESTURE: Move a magnified photograph about
// where: Develop
// touch: Drag it
// pointer: Drag it
// why: Only once there is something outside the
// viewport to reach, which is why the
// cursor becomes a hand exactly then. The
// view is clamped to the frame: panning
// past the edge would show undefined area
// beside the photograph, and that reads as
// a rendering fault rather than as the end
// of the picture.
moved => {
if (self.pressed && root.zoomed) {
// Fractions of the *visible* area, which is what
// the session's pan expects. Negated: dragging
// right moves the image right, so the window onto
// it moves left.
root.pan-by(
-(self.mouse-x - self.last-x) / max(parent.shown-w, 1px),
-(self.mouse-y - self.last-y) / max(parent.shown-h, 1px),
);
self.last-x = self.mouse-x;
self.last-y = self.mouse-y;
}
}
scroll-event(ev) => {
if (ev.delta-y == 0) {
return reject;
}
// Anchored on the pointer, in fractions of the shown
// image, so whatever is under the cursor stays there.
root.zoom-at(
ev.delta-y > 0 ? 1.15 : 1.0 / 1.15,
(self.mouse-x - parent.shown-x) / max(parent.shown-w, 1px),
(self.mouse-y - parent.shown-y) / max(parent.shown-h, 1px),
);
return accept;
}
// TRACES: FR-UI-4
// Fit and 1:1, which is what FR-UI-4 asks a double
// tap for. It used to drop straight to fit, so the
// gesture only ever did half its job — and the half
// it did not do is the one that matters, since
// nothing else in the interface reached 100% at all.
//
// Anchored on the pointer, in fractions of the shown
// image, exactly as the wheel above is: the detail
// being inspected is the one under the finger, and a
// toggle that jumped to the centre would ask for a
// pan afterwards every single time.
double-clicked => {
root.inspect-toggled(
(self.mouse-x - parent.shown-x) / max(parent.shown-w, 1px),
(self.mouse-y - parent.shown-y) / max(parent.shown-h, 1px),
);
}
}
// Region picking, declared after the pan/zoom area so a
// click reaches it first — see the note there for why that
// is the way round it is. A separate area rather than a
// branch inside it: panning wants press-drag-release and
// picking wants a click, and interleaving the two in one
// handler is how a drag ends up selecting a region the
// user was only scrolling past.
if root.region-picking && root.total > 0 && root.load-error == "": pick := TouchArea {
x: parent.shown-x;
@@ -2125,85 +2230,6 @@ in property <bool> panel-visible: true;
}
}
if root.total > 0 && root.load-error == "": TouchArea {
x: 0; y: 0;
width: 100%;
height: 100%;
// A pan is only meaningful once there is something outside
// the viewport to reach.
mouse-cursor: root.zoomed ? MouseCursor.grab : MouseCursor.default;
enabled: !Develop.cropping;
property <length> last-x;
property <length> last-y;
pointer-event(ev) => {
if (ev.kind == PointerEventKind.down) {
self.last-x = self.mouse-x;
self.last-y = self.mouse-y;
}
}
// GESTURE: Move a magnified photograph about
// where: Develop
// touch: Drag it
// pointer: Drag it
// why: Only once there is something outside the
// viewport to reach, which is why the
// cursor becomes a hand exactly then. The
// view is clamped to the frame: panning
// past the edge would show undefined area
// beside the photograph, and that reads as
// a rendering fault rather than as the end
// of the picture.
moved => {
if (self.pressed && root.zoomed) {
// Fractions of the *visible* area, which is what
// the session's pan expects. Negated: dragging
// right moves the image right, so the window onto
// it moves left.
root.pan-by(
-(self.mouse-x - self.last-x) / max(parent.shown-w, 1px),
-(self.mouse-y - self.last-y) / max(parent.shown-h, 1px),
);
self.last-x = self.mouse-x;
self.last-y = self.mouse-y;
}
}
scroll-event(ev) => {
if (ev.delta-y == 0) {
return reject;
}
// Anchored on the pointer, in fractions of the shown
// image, so whatever is under the cursor stays there.
root.zoom-at(
ev.delta-y > 0 ? 1.15 : 1.0 / 1.15,
(self.mouse-x - parent.shown-x) / max(parent.shown-w, 1px),
(self.mouse-y - parent.shown-y) / max(parent.shown-h, 1px),
);
return accept;
}
// TRACES: FR-UI-4
// Fit and 1:1, which is what FR-UI-4 asks a double
// tap for. It used to drop straight to fit, so the
// gesture only ever did half its job — and the half
// it did not do is the one that matters, since
// nothing else in the interface reached 100% at all.
//
// Anchored on the pointer, in fractions of the shown
// image, exactly as the wheel above is: the detail
// being inspected is the one under the finger, and a
// toggle that jumped to the centre would ask for a
// pan afterwards every single time.
double-clicked => {
root.inspect-toggled(
(self.mouse-x - parent.shown-x) / max(parent.shown-w, 1px),
(self.mouse-y - parent.shown-y) / max(parent.shown-h, 1px),
);
}
}
// --- crop overlay ------------------------------------------
//