A photographer cropping for a print, a phone wallpaper or a 16:9 frame is
not choosing four edges — they are choosing one edge and a known shape.
Free-dragging every corner made them do that arithmetic by eye on every
drag, and get it slightly wrong.
The panel now offers Free, Original, 1:1, 3:2, 4:3 and 16:9, with a
Portrait switch for the ones that have two orientations. Original follows
the frame rather than naming a number, so it stays right on the next
photograph from another body and after a quarter turn.
**The ratio is of output pixels, and the rect is not.** `CropRect` is
stored in fractions of a frame that is not itself square, so holding a
shape needs the frame's size — `ratio * height / width` of the frame.
Skipping that gives a "1:1" crop that is square only on a square
photograph, which is the one case nobody would test on, so the conversion
lives in `CropRect::with_aspect` where it is explained and pinned by a
test that asserts the fractions are *not* equal.
Two decisions worth recording:
The reshaped rect **grows** onto the ratio rather than shrinking onto it,
then scales down only as far as the frame's edge demands. Fitting inside
instead makes a one-axis drag do nothing at all — the other axis clamps
the first straight back, and the handle simply refuses to move.
The overlay now reports **which corner the drag is holding**, because
reshaping onto a ratio has to know which corner is nailed down and only
the handle that took the press knows that. A move reports no corner and
keeps its shape: reshaping about a centre would pull an over-moved rect
smaller instead of sliding it along the edge.
The lock lives with the window rather than the session. A `DevelopSession`
is per image, and cropping a set of frames to one shape is exactly when
the lock earns its place. It is not an edit and reaches no sidecar — what
is saved is the rectangle it produced.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dragging the crop rectangle tracked the pointer at half speed: the rect
slid out from under the cursor, and the handle being held stopped being
the one under the finger. On a photograph where the whole point is to
place an edge by eye, that made the tool close to unusable.
The cause is that a `TouchArea` reports `mouse-x` relative to itself, and
every area in the overlay is positioned *by the very rect the drag is
editing*. Rust echoes the applied rect back on each step, so the area
moves under the pointer and the reported position falls by exactly the
amount it had just risen. `mouse-x - pressed-x` therefore subtracts the
drag from itself, and the fixed point of that feedback is a rect that
moves half as far as the pointer does — which is why it looked like
sluggish tracking rather than like a coordinate bug.
Both terms are now taken in the frame's own coordinates: `parent.x +
mouse-x`, where `parent.x` tracks precisely the movement `mouse-x` lost,
with the press captured in those same coordinates on the way down. The
two movements cancel and the rect follows the pointer exactly.
`GradientHandles` in masks.slint was already written this way, and for
the same reason — its handles are placed by the mask they drag. The
header note here now says why the shape matters, since the wrong version
compiles, looks plausible, and is only wrong once the rect starts moving.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The crop rectangle, the gradient handles and the repair discs were 480
lines inside `canvas-area` in app.slint, while the panels that drive them
already lived in adjust.slint, masks.slint and spots.slint. spots.slint
even opens by describing "what is drawn over the photograph, and what a
finger can take hold of" -- which was not in it.
They stayed behind because all three are positioned against `shown-*`,
the fitted image rect the develop view derives because Slint does not
report it. That is now the interface rather than the obstacle: each
overlay is *given* that rect as its own bounds, so every position inside
is a plain fraction of `root.width`, and none of them reaches out to
`canvas-area` for an origin any more.
GradientHandles joins MaskPanel in masks.slint and SpotHandles joins
SpotPanel in spots.slint, each file now holding one domain's panel and
its canvas overlay together, matching masks_ui.rs and spots_ui.rs.
CropOverlay gets crop.slint of its own rather than growing adjust.slint.
Arithmetic is unchanged: the old fraction-x subtracted shown-x from a
coordinate measured relative to canvas-area, and the new one measures
from an origin that already is shown-x. The handles stay unconditional
rather than gaining an emptiness guard, so the repeater identity that
spots_ui::sync_handles warns about is untouched.
app.slint: 2834 -> 2490 lines. Verified by running the desktop app on a
photograph, with the crop overlay's guard temporarily forced open so all
three instantiate -- no binding loop, no panic.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dtourolleandClaude Opus 5