1026 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
dtourolle	4574c35236	Let a part be left out of a mask without being taken out of it ... A layer built from parts was missing the one control a correction most often wants: seeing what it did. The question a subtracted gradient raises is whether it took only the sky, and the question a stroke raises is whether it filled the shoulder — and the only way to ask either was to remove the part and look, which answered the question and lost the part. The layer's own ring answers a different question, about the adjustment, and hiding eight layers to check one correction is not an A/B anybody performs. So a part carries `hidden`. It is an edit and a history step, as the layer's switch is, and it is folded into the render fingerprint because hiding a part changes the mask as surely as removing it does. Where the mask is built the shown parts are walked rather than the parts, which is what makes a hidden base hand the fold to the first part that is shown — and a revealed layer whose every part is hidden clears its slice rather than leaving whatever the last rasterisation put there to be read back. `covers` asks the same shown parts, so a layer whose only adding part is hidden costs no slice at all. In the sidecar the key is `hidden`, in the part's block or, for the base, in the mask block — under a word that cannot be confused with the layer's `enabled`, which has always meant the layer. Absent means shown, so no file written before the switch existed reads any differently. The row wears the same ring the layer does, one row down, because it is the same question about a smaller thing.	2026-09-12 01:08:10 +02:00
dtourolle	9cc52fd72b	Bind the two develop gestures that were described and not bound ... FR-DEV-16's book said resetting a control and hiding a mask layer were reachable by pointer and by finger, and stopped there. The reason was honest: the generated rows have no focus, so "reset the focused control" named a thing the panel could not point at. But a photographer at the keyboard means something narrower than focus. They mean the slider they just dragged too far, and that is a thing the panel can remember. So the Adjustments global keeps the last control moved — two indices, written where the panel forwards the change and cleared when the next photograph opens, so a reset cannot reach back into the previous edit through an index that happens to be shared. R puts it back, through the same callback the track's double-click takes, and is silent until something has moved. The mask layer needs no such notion, because the panel already has a selection: the rows the edge controls point at. H hides or shows those, through the path the ring at the head of the row takes, so it is an edit and a history step exactly as the ring is. A mixed selection goes to shown, since the layer nobody can see is the one being asked about. Both tags now carry the key, and the book says so.	2026-09-12 01:08:09 +02:00
dtourolle	2836ec2881	Build the Windows installer in a container, and run it under Wine ... docs/windows.md specified it; this is §9 steps 1, 2 and 4 run, and the report in §10. A Debian trixie image with rustup, the MinGW cross compiler, NSIS and Wine; a build.sh in the shape of the Android one; a package.sh that stages the executable and the seven models behind the same LFS-pointer guard every other packager carries, then runs makensis; and the .nsi itself — per-user, no elevation, an uninstaller that leaves the library alone. Measured: the executable links first time once the link flags were right, imports only Windows system DLLs, prints its version under Wine, and the installer installs and uninstalls silently under Wine with the registry key and the models where §5.2 says. What Wine cannot show is the Start Menu shortcut: CreateShortcut is IShellLink and does nothing headless. Four claims in the spec's first draft were wrong and are corrected in place with the reasoning kept: the whole-archive winpthread flag breaks the link and was never needed; build scripts need a host gcc; bookworm's Wine lacks the bcryptprimitives.dll rustc's std imports, so the image is trixie; and NSIS's default stub is 32-bit, so the installer says amd64-unicode and needs no i386 Wine.	2026-09-12 00:54:11 +02:00
dtourolle	fa4dca327f	Give the desktop executable a version flag and a Windows identity ... Three things the Windows build showed the entry point was missing, and that a Linux build never asks for. `--version`, answered before the logger and the crash hook install: a binary built on a machine that cannot run the application — the Linux CI producing the Windows executable, checked under Wine — needs an exit that proves it starts without opening a window or touching the user's directories. It is the smoke test in docs/windows.md §6. A GUI-subsystem executable in release, or Windows keeps a console window open behind the application for the life of the process. Debug builds keep the console, which is where their log goes. A resource block, or Explorer, the Start Menu and the taskbar show the generic executable icon and the Details tab is empty. build.rs wraps the PNG every other platform uses into an .ico at build time — an ICO entry may be a PNG, so the wrapper is a 22-byte header — and hands it to winresource with the version cargo already knows. The crate is an unconditional build-dependency because a cfg(windows) on one is evaluated against the host, which here is Linux; the script itself returns before touching it on any other target.	2026-09-12 00:54:11 +02:00
dtourolle	0a2c49dd10	Guard two constants the Windows target leaves unused ... secrets.rs names the keyring service and desktop_client.rs the socket timeout, and every use of both sits under a cfg that a Windows build does not satisfy — the placeholder secret store has nothing to file under, and the Nextcloud client's named pipe is not opened yet. The first cross-compile reported both as dead code, which is a failed clippy job the moment the Windows leg runs with -D warnings. Guarded by the same cfgs as their users, with the reason beside each.	2026-09-12 00:54:10 +02:00
dtourolle	b718c70b11	Specify a Windows installer built by the Linux CI ... The tree is closer to Windows than a Linux-only project usually is: every image library, the TLS stack and the inference engine are pure Rust, and dr-plat already keeps the Linux-only code behind cfgs with a loud fallback where none exists for another platform. What remains is a short list above dr-plat — five XDG path lookups, an xdg-open, the secret store's third implementation, the models' lookup beside the executable — and none of it touches core, which is the NFR-PORT-3 test this would be the first real run of. docs/windows.md decides the GNU target over MSVC-via-xwin, Vulkan only as on every other platform, a per-user NSIS installer that leaves the library alone on uninstall, and a CI leg in the shape of the Android one. It is explicit about what a runner with no Windows can verify — that it links, is PE32+, starts under Wine and installs under Wine — and what it cannot, which is everything involving a real GPU driver. Three FR-PLAT-WIN requirements and a channel row record the decisions; the ordering puts a first cross-compile on the developer machine before any container exists, because the list of cfg gaps is a reading of the source and the compiler's list will be longer.	2026-09-11 23:30:16 +02:00
dtourolle	a2c7789007	Sign the Android build with a real key, and let package.sh use it too ... The release keystore now exists and its four secrets are loaded into Gitea, so CI produces an APK a device can update in place. Until now every build, CI and local alike, was signed with a throwaway debug key -- CI's fresh per run, the local one exactly as durable as the cache directory it lived in -- and the night that cache was cleared, no build anywhere could install over the tablet's copy. package.sh forwards KEYSTORE_PASS, KEY_PASS and KEY_ALIAS into the container and copies the keystore under the mounted target directory for the build, so a local release-signed build is one environment line. The doc records where the local copy of the key lives. v0.12.0	2026-09-11 23:22:28 +02:00
dtourolle	7c44740d9f	Skip the read-only-directory test where modes are not enforced ... `a_failed_overwrite_puts_the_original_back` makes the presets directory read-only and expects the overwrite to fail. CI's Desktop job runs in a container as root, and root is not refused by a mode: the write succeeds, the assertion fails, and build-and-test has been red on every push to master since the test arrived. The test now probes the refusal it depends on -- one write into the directory it just locked -- and skips where that write goes through. Probed rather than keyed on the uid, because what the test needs is the refusal itself, and a filesystem mounted without permission checks would pass a uid test and fail this one all the same.	2026-09-11 22:22:46 +02:00
dtourolle	4f31123b0c	Let the user choose which SCRFD finds their faces ... faces.md §12.3 measured what the cheapest detector costs: the small faces in every group shot, and a dog embedded a dozen times. Which trade is right depends on the machine doing the sweep — a desktop left overnight and a tablet on a battery want different answers — so the detector is now a per-device setting, Fast / Balanced / Thorough on the settings page beside the indexing button, persisted with the rest of the settings file. A detector is half of a model id. Every face, marker, shard and calibration is keyed on faces.model_id precisely so that a model change is a new id and a re-index rather than a silent change under existing data, and a detector change is a model change: it decides which faces exist and where the landmarks that align them land. So each choice names its own pipeline. 500M keeps the bare "w600k_mbf" every existing library was written under, so an upgrade disturbs nothing; the others are qualified. Choosing one restarts coverage from zero under the new id, the sweep re-detects, confirmed names carry across by box overlap, and the sync shards are keyed by the same id so a peer on another setting neither adopts nor pollutes them. The library controller carries the id into the sync the same way it carries the cache budget, because the sync starts from places that have no settings in reach. All three shape-fixed exports ship — APK, Arch, Flatpak — since a tablet has no other way to obtain the one it was not installed with; the APK grows by twenty megabytes for the choice.	2026-09-11 22:12:53 +02:00
dtourolle	adf5d6cdd9	Drop a rival pipeline's marker when an image is re-indexed ... record_detections replaces every face on an image whatever model found them, but left the other models' face_index rows standing. With one model that was unobservable. With a second pipeline it leaves an image marked "done" under the first with none of its faces behind the marker — the state the V12 repair existed to undo — and a user who switched back would find those photographs permanently empty. An image now holds the faces of whichever pipeline looked at it last, and only that pipeline's marker. Confirmed names still carry across by box overlap, since they were read before the replacement.	2026-09-11 22:12:40 +02:00
dtourolle	9d35addd86	Measure what the cheapest SCRFD actually costs in faces ... §1 chose scrfd_500m on FLOPs and never measured the recall it gave up. A dr-ui example now runs several detectors over the same sample of stored proxies, matches boxes by IoU against the first, buckets the result by face size, times each, and writes contact sheets of the disagreements in both directions — because a count of extra faces says nothing until someone has looked at whether they are faces. Over 400 proxies from the reference library: 2.5G finds 14% more faces for 12% more time, 10G a further 12% for 3.1× the time. The extras are small real faces. The 86 faces only 500M found are a dog a dozen times, a stop sign, a wheel and the backs of heads. Recorded in faces.md §12.3.	2026-09-11 22:12:39 +02:00
dtourolle	3d6d69ec90	Wrap the face-sweep repair match the way rustfmt wants it ... CI's Desktop job failed at the Format step on 16f3fb4: rustfmt puts the `match faces_without_proxy(...)` on its own line under the `let` and re-indents its arms, and the commit was written without running it. No code changes; only the layout of that one match in library.rs.	2026-09-11 22:00:38 +02:00
dtourolle	16f3fb41a3	Measure the faces already found rather than finding them again ... Every face stored before its quality was kept holds a unit vector, and V14 forgot the run marker of each image holding one so that the next sweep would look again. Looking again meant detecting again: a whole re-detection per image, with every suggestion on it thrown away and the confirmations carried across by box overlap, to recover one number. The sweep now has a measuring pass between the proxy repair and the un-indexed images. It lists every image holding an unmeasured face, fetches the original once, warps each stored face from the landmarks it already has, embeds it, and writes the raw vector and its length over the old row. Ids, boxes and identities are untouched; the marker is re-written fresh so the sync exports the measured vectors. A face whose landmarks no longer make a warp is dropped, as detection would have refused to store it. `faces_unindexed` leaves those images to the measuring pass, so the V14 deletion no longer costs a second detection.	2026-09-11 21:50:12 +02:00
dtourolle	8b3abdb787	Keep each face's quality, and never compare against a poor one ... The embedder's raw output has a length, and the length is a reading of how recognisable the crop was: a blur, an occlusion or a hard profile comes out short. Normalising threw it away. A short vector sits near the middle of the sphere and matches a little of everyone, which is how one bad crop bridges two people in a grouping pass. So the length is kept — the store now holds the raw vector, re-normalised on load, with the length beside it as `faces.quality` — and a face under MIN_GALLERY_QUALITY (14) is a probe: measured against the gallery and placed where it fits, but never what another face is measured against. Two probes are never paired, and a probe is nobody's evidence for a confidence. The People screen shows the number as "Quality 17.3", dimmed below the floor. Faces indexed before this stored unit vectors and have no reading; they are admitted to the gallery, and schema V14 forgets the run marker of every image holding one so the next indexing pass measures them. A peer's unmeasured shard faces are not adopted, or a sync would write that marker back.	2026-09-11 21:50:12 +02:00
dtourolle	a87139b838	Give every mask an eye and a colour, and put the brush where the mask is ... The first build of seeing a mask showed the selected layer's, in one global style, from a strip at the top of the panel. It answered the wrong question and answered it somewhere nobody looked. What a photographer asks of two masks is how they meet — where the sky's edge sits against the building's — and that needs both on screen at once, in colours that can be told apart. So each row of the stack has an eye, drawn in the colour its mask is shown in, and each mask has six swatches to choose that colour from. Several can be open at once; a new one comes up open, in the first colour nothing else is using. The style — tint, alpha, outline — is the one setting that stays global, above the stack, because three styles at once are three pictures that cannot be read against each other. Alpha now draws every shown mask, each in its colour, on black. In the pipeline a `Reveal` is a list of `(layer, colour)` rather than one layer, and every reveal block carries its own colour. The brush moves too. Select, Paint and Erase and the three sliders under them sat at the top of the panel, appeared only once a row was selected, and said nothing about which mask they acted on — so "how do I paint" and "how do I correct the model's outline" both had the same answer and nobody found it. They sit under the selected mask's parts now, beside the swatches, and on a subject or a category the hint says what a stroke there does: it becomes a part of this mask, joined to the model's, and can be taken out again. Eyes and colours are viewing state, on the session and not on the layer, so a photograph reopened has every eye closed — the stored-mask round-trip test asserts it.	2026-09-11 19:03:51 +02:00
dtourolle	936490880b	Release 0.12.0	2026-09-11 09:33:36 +02:00
dtourolle	d8b9b5a4bb	Let the release script write the release commit it was never trusted with ... Every release commit in the history reads `Release X.Y.Z` and none of them carries the message this script would have written, so nobody has ever passed it `--commit` — and the reason is in the message it wrote: a Co-Authored-By trailer naming an assistant, which no commit in this repository carries and none should. The trailer goes, and so does the paragraph above it: the script's own header already says why it exists, and a release commit is the one place a one-line subject is the whole convention.	2026-09-11 09:33:28 +02:00
dtourolle	ac0aea70ec	Show a mask as soon as it is made ... Choosing a category is asking what it selected, and for a subject or a category that question had no other answer on screen: the model's outline is not derivable from anything visible, a fresh layer carries no adjustment to judge it by, and the list it was chosen from says "architecture 23%" without saying which 23%. The control that draws the mask existed but had to be found and pressed, a panel's height away from the list the choice was made in. So a new layer arrives with its mask showing, from the resting position only. Somebody who has chosen the alpha or the outline keeps it, and nothing re-arms in the background — every caller is a press that asked for a new mask. That makes the canvas depend on how a layer arrived, which is correct and worth stating: a session that has just made a mask draws a frame that a session which read the same mask out of a sidecar does not. Viewing state is not edit state and does not travel in a file, and `a_stored_mask_renders_exactly_what_the_model_rendered` now says so at both ends.	2026-09-10 20:56:11 +02:00
dtourolle	5d175cc668	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.	2026-09-10 20:56:10 +02:00
dtourolle	76ad667fd6	Offer a mask that is nothing but a hand ... Every route to a layer began with a selection — a gradient, a band, a subject, a category — and painting was reachable only by making one of those and joining a painted part to it. So the answer to "brush a correction onto this corner of the sky" was "add a radial gradient you do not want, then paint into that", which is not an answer. Paint sits beside Linear and Radial and makes a layer whose base is a brush. It covers nothing until a stroke lands in it, so pressing it arms the brush and shows the mask as well: a row that appeared and changed no pixel, with the pointer still in "select", is indistinguishable from a button that did nothing.	2026-09-10 20:28:09 +02:00
dtourolle	c045702a47	Show the photographer the mask they are shaping ... Nobody can refine an edge they are not being shown. The only thing drawn on the canvas was the region overlay — a false-coloured picture of what the model *detected* — which knows nothing of a layer's feather, its falloff, its morphology, its invert or its opacity, and nothing at all about a gradient, a range or a stroke. Every control added for mask editing therefore acted on something invisible, which is why the whole feature reads as absent rather than as unfinished. A layer's finished mask now draws over the photograph in one of three styles: a tint for whether the right thing is selected, an alpha for where the edge is, an outline for whether that edge is registered against the detail the other two hide. The hard part is not the shader. A selection with no adjustment on it changes no pixel, so it is not active, so it holds no slice of the mask array and is never rasterised — and that is exactly the layer somebody wants to look at, for the whole of the time between choosing a subject and deciding what to do to it. So `MaskStack::rendered` is `active()` plus the layer being looked at, and the rasteriser, the composer and the distance-field builder all index by position in it. Which is also why the design's "two uniforms, no recompile" is not available: a uniform can select a slot, it cannot conjure one. The reveal is never on the graph. It reaches the pipeline as an argument to `compose_revealing`, and `compose_for` — which the exporter, the thumbnail and the neutral probe all call — has no way to ask for one. A flag on the graph would have been shorter, would have type-checked, and would have been one forgotten reset away from a red tint baked into an exported file. And the tools that shape a mask now arm. `Masking.tool` is an `in` property only Rust may write, and the handler wrote nothing back, so the strip reported "Select" however many times Paint was pressed and the paint area was never enabled — the brush, the parts and the whole of FR-DEV-19b reachable from no control in the application. The region overlay stands down while a mask is being shown, and its button now says what it hides: two overlays that look alike and mean different things is worse than either.	2026-09-10 20:28:06 +02:00
dtourolle	193b35a249	Start a category mask where the photograph can bear it ... Clicking "architecture" made a layer whose mask was gone. Every category layer began at STRICTNESS_DEFAULT, and that constant was fitted on the synthetic sky the refine tests build — its own note warns that a real photograph's noise "moves every crossing down together", which turns out to be a considerable understatement. Measured over seven ordinary frames, half scale removes 76% to 99.5% of `architecture`, 36% to 93% of `ground` and 18% to 91% of `vegetation`. Only sky, the category the number was calibrated against, survives it. An empty mask is indistinguishable from a broken one: the layer is listed, the adjustment moves, and no pixel changes. So what this looks like from outside is that the segmentation does not make masks at all. No smaller constant fixes it either, because a nat of evidence means different things over a smooth sky and over a stone facade — the useful position is above 5 on one frame and below 1 on the next. So the frame is asked instead: `Refinement::gentle` walks down from half scale and takes the first rung whose gate removes no more than a sixth of the category's weight, and the model's own outline when none of them does. One `apply` on a friendly photograph and four on an unfriendly one, paid when a layer is made rather than for eight categories nobody masked. The slider's reset went to 4 as well, so taking the control back to its "default" emptied the mask. It goes to zero now, which is the one position documented to mean something: exactly what the model weighted.	2026-09-10 20:27:40 +02:00
dtourolle	404fea47a8	Wrap the lines the merge resolution left long ... `cargo fmt --check` failed the desktop job, on three files and for one reason: routing the mask handlers through the `Masking` global was done by substituting the call prefix, which is a text edit rather than a Rust one. It left `window.global::<Masking>().on_part_join_picked(...)` on a line that had been short enough as `window.on_mask_part_join_picked(...)` and no longer was. Formatting only. The whitespace-stripped source is identical in the two `ui/` files; the third differs by the trailing commas rustfmt adds when it breaks a call across lines. The matrix moves with it, because the tags shift by a few lines and the check compares line numbers. v0.11.0	2026-09-08 08:57:32 +02:00
dtourolle	d920716a2b	Release 0.11.0	2026-09-07 22:31:53 +02:00
dtourolle	2d878c2117	Offer the film stock in its own group, and let its list scroll itself ... Two faults in one control, both reported from the tablet. The stock picker appeared in every group. It is not a parameter, so it is not a row, so the filter that hides every other control when a group is chosen never saw it — "Kodachrome" sat at the top of Light, of Colour and of Detail alike. Three places it does not belong, and the one it does no more prominent than the rest. The descriptor has said `Effect` and only `Effect` since the film moved there; nothing was asking it. So the panel now asks. It cannot ask directly — a generated panel may not know which operation a control belongs to — so the session answers, from what the operation declares it is about, and a stock re-declared as something else would move on its own. The flag is recomputed when the group changes as well as when the film does, which is the half that would have made it stale exactly when it mattered. And the open list was unbounded, so it made the develop column taller and the column scrolled as one: reaching Velvia dragged every slider below it off the screen, an answer given once pushing aside the controls used constantly. It now scrolls within a bounded height of its own. That viewport is counted rather than measured, for the reason the tool rail records a few files away: a viewport that asks a layout how tall it wants to be, while the layout takes its height from the viewport, is a cycle Slint settles by handing back the height it was given — and the content is then clipped in silence rather than scrolling. Every row here is one fixed height, so multiplying is exact. The group rule has a test. The scrolling does not, and cannot: it is a layout, and a layout fault is invisible to the compiler and to every assertion that can be written about it.	2026-09-07 20:42:15 +02:00
dtourolle	4c217c9be6	Show what a control does to a photograph, one parameter at a time ... A node that has just been declared can be read, reasoned about and tested, and none of that answers the question a photographer asks first: what does moving this do to the picture. Colour grading, dehaze and the range masks were all argued into the tree on their behaviour and none of them had been *looked* at. So two diagnostics. `sweep` walks one operation from its minimum to its maximum and writes a frame per step; `rangesweep` does the same for a mask band, which is not an ordinary parameter — it lives on a layer, is rasterised by its own pass, and only becomes visible through whatever adjustment the layer carries, so it gets two stops down to make the selection legible. `sweep` names no operation. The id arrives as a string and the parameters and their ranges come from the graph's own capabilities, so a node declared yesterday sweeps on the same terms as one that shipped a year ago — the property `ops/README.md` promises, used rather than asserted. Three things it learned the hard way and now records. It renders through `render_detailed` unconditionally, because the fused path refuses a shader composed with a detail stage rather than rendering it wrongly, and that call falls through when there is no such stage. It takes `SWEEP_HOLD`, because a parameter grouped under one widget is not meaningful alone: a hue with no strength behind it renders the same frame every time, which reads as a broken node rather than a correctly declared neutral. And it bounds the output, since a 25 MP frame is a 75 MB PPM and a sweep is hundreds of them. Both read a rendered file as readily as a raw one, so a JPEG can stand in where no raw is to hand — on the terms `from_rgba8` documents, with the controls still working and their neutral being what the camera left rather than what the sensor recorded.	2026-09-07 20:01:08 +02:00
dtourolle	e44cb8cbe0	Regenerate the traceability matrix for the rebased line numbers	2026-09-07 20:01:01 +02:00
dtourolle	0a5eab0487	Wire the develop panels through globals, so a second copy is one line ... Every panel in the develop column declared its inputs and its callbacks and had `app.slint` bind each one to a property or a callback on the window root. That is fine while a panel is drawn once. N9 draws them a second time, in the portrait dock, and the wiring is what would have to be copied: `MaskPanel` alone ran to forty lines of forwarding, and a callback added to one copy and not the other compiles, renders, and simply does nothing on the layout nobody was looking at. So the wiring moved to Slint globals. A panel reads the global and calls the global; Rust hooks the global instead of the window; and the instantiation in the column is now the panel's name and a pair of braces — every one of the ten children of the column, with no property that differs by placement left to supply. There is a global per panel family rather than one for all of them, and the reason is an import cycle. Each panel's model struct — `ParamRow`, `MaskRow`, `HistogramView` — is declared in the panel's own file, so a single global holding `[MaskRow]` and `[ParamRow]` would have to live in a file importing `masks.slint` and `adjust.slint` while both imported the global back, which Slint rejects. Breaking that needs six model declarations relocated, which is a change to the data model and not to the plumbing this is about. A global beside the panel it serves also lets each name drop the prefix it was carrying only because the window root is one flat namespace: `root.spot-radius` is `Repair.radius`, and `root.peaking-on` is `Peaking.showing`. `session.slint` is new and holds the two facts every family needs and none of them owns: whether there is an open photograph to edit, and which mode the view is in, with the three readings of the mode derived once instead of at each of the dozen places that tested one. `ViewMode` moves there from `adjust.slint`, where it was only ever a lodger. Nothing on screen changes. What is not here: the tool rail and the status strip still take their properties at the instantiation, because they are drawn once and N9 does not copy them; the preset sheet's own state stays on the window, because the library grid opens the same sheet and a global cannot bind the window's state — which is why `Transfer.open-presets` is handled in `presets.rs`, beside the summary it already had to compute.	2026-09-07 20:01:01 +02:00
dtourolle	dd14243dba	Lay the develop view out by coordinate, so the column can sit below ... Slint cannot turn a layout on its side, and that is what D-N7 asks for. So the HorizontalLayout holding the rail, the canvas and the develop column becomes a plain Rectangle and each of the three states its own x, y, width and height. With `column-below` false those come out where the layout put them to the pixel — a HorizontalLayout has no spacing or padding of its own, the rail and the column took their declared widths at the two edges, and the canvas was the only child that stretched. The alternative was the column subtree declared twice under two `if`s, which is four hundred lines of bindings copied, in a file whose own notes record a conditional child in a layout as the shape that has produced binding loops here before. The column is the same column either way: the same contents, the same Flickable, the same toggle. `panel-visible` collapses the dock's height exactly as it collapsed the column's width, so `column-width` and `dock-height` are each zero unless the column is both open and on that axis, and the canvas can subtract both without asking which case it is in. The stack inside stretches to the dock's width on its own — a layout that is the direct child of a Rectangle fills it, and the Flickable's viewport was already bound to its own width. Nothing is reflowed; N9 does that. `dock-height` is mandated in style.yaml for the reason `panel-width` beside it is, on the other axis: a dock that sizes itself to its contents is a photograph that changes height when a caption wraps. 480 until N6 measures the device. The seam follows the column round: a hairline down its left edge beside the photograph, along its top edge under it, so it stays between the two.	2026-09-07 20:00:50 +02:00
dtourolle	5f0b11c1f4	Ask the window how tall it is, and say when the column belongs below ... D-N7 puts the develop column under the photograph on a tall window, and the axis it turns on is aspect rather than width: a 960-wide portrait tablet is expanded by width and wants the dock, a 1500-wide landscape desktop is expanded by width and does not. So this cannot be folded into the layout class, and it is not remembered per class either — closing the column in landscape closes the dock in portrait, because it is the same column. `window-resized` reported width alone and now reports both, from a `shell-height` that subtracts the safe-area insets exactly as `shell-width` subtracts them: on Android the strips the status and navigation bars occupy are on the axis being measured, so the aspect of the window and the aspect of the space the interface actually gets are not the same number. `column_below` is the decision, with two thresholds rather than one. It is read on every resize event, and a single threshold means a window dragged along its own diagonal crosses it several times a second while the pointer is still down. Entering at 1.25 and leaving at 1.15 is a dead band no plausible drag re-crosses. The comment on EXPANDED_MIN_WIDTH claimed a tablet in portrait gets the compact layout. It does not — its panel is about 960 logical pixels across, which clears 820 — and that mistaken example is the one D-N2 reasoned from. Corrected in the same breath, since this is the commit that says what portrait actually changes.	2026-09-07 20:00:50 +02:00
dtourolle	30468c4c69	Put the window-metrics doc on the function it describes ... The comment explaining why both coordinate systems go on one line was written for `log_window_metrics` and sat above `window_metrics_level`, where it read as the start of that function's much longer note. Two doc blocks ran into each other and the one that prints had none.	2026-09-07 20:00:50 +02:00
dtourolle	428d8c4a51	Say what size the window actually is, in both coordinate systems ... Every figure in D-N7's table was computed at a guessed scale factor. The tablet's panel is 3000 by 1920 physical and nothing in this repository has ever recorded the density Android reports for it, so the dock's width is either 900 or 1037 and its available height is 200px either way. N6 asks for the measurement; this is the line that carries it. Beside the existing `apply_layout_class` call, because that is where the window is already being asked for its size and its scale, and again on every resize, so turning the tablet over records the other orientation in the same logcat. Both coordinate systems on one line: a logical size cannot be checked when the scale is the thing in doubt, and a physical size that does not divide by the scale printed next to it says the reading is of something other than the panel. The level is not fixed, because none of the three obvious choices works. `android_main` caps the facade at info, so debug never leaves the device and a debug-only line answers nothing. A drag emits a resize per frame and each accepted record is also appended to the on-disk log, so info on every resize is not a diagnostic. And the first reading is not the settled one: on X11 the window reports 0x0, then 360x320 at scale 1.0, then 1100x720 at scale 2.0, so reporting only the first would put a number in logcat that is not the window's. So the pair that decides is the scale factor and the orientation -- exactly what N6 is asking for, and exactly what a drag leaves alone. A window with no area is not a reading and records nothing. Every later change to either half, the scale resolving or the tablet turning over, is a new answer and goes out at info; everything else is debug.	2026-09-07 20:00:49 +02:00
dtourolle	2361b2d4ef	Tablet portrait is the expanded layout class, not the compact one ... FR-UI-1's table has put tablet portrait in the compact class since the register was written. D-N2 settled that it does not belong there: a 12-inch tablet is about 1024 logical pixels across in portrait and EXPANDED_MIN_WIDTH is 820, so both orientations of both targets are expanded, and compact fires only on a desktop window dragged narrow. The code has always agreed - apply_layout_class reads the window's width and nothing else - so the register was the last place still saying otherwise. What portrait actually needed was a different axis. D-N7 docks the develop column under the photograph on a tall window, set from the window's aspect and independent of the layout class: a 960-wide portrait window is expanded and wants the dock, a 1500-wide landscape one is expanded and does not. That is a placement rather than a mode, so the clause about the transition being continuous stands as written, and the requirement now records the side the column takes as its own property. FR-UI-2 gains one clause for the same reason. It said modality affects control sizing and affordances "not layout", which D-N6 reversed: under touch the group selector leaves the strip above the column for the tool rail, and groups-in-rail in toolrail.slint is what moves it.	2026-09-07 20:00:40 +02:00
dtourolle	de32c04a68	Dock the develop column under the photograph on a tall window ... D-N2 dismissed portrait with one number: a 12-inch tablet is about 1024 logical pixels across, which clears the expanded breakpoint. That was worked out for a 4:3 panel. The tablet's is 3000 by 1920, and on that aspect a column beside the photograph in portrait leaves it a strip 540 wide and 1456 tall: a 3:2 frame gets 540 by 360 where a column below it would give 900 by 600, and the portrait frame gains too. D-N7 records the decision: a third property beside the layout class, derived from the window's aspect with hysteresis, that lays the same rail, canvas and column out on the other axis. Not a sheet, not a second layout, and the rail does not move. N6 measures the device the numbers were guessed for, N7 does the frame with the stack stretched as a stopgap, N8 moves the develop callbacks onto a global so the panels can be declared twice cheaply, and N9 is the three-column composition the dock's width is actually for. N5's "no strip along the bottom" is struck where D-N7 reverses it and kept where it does not.	2026-09-07 20:00:40 +02:00
dtourolle	e13d3a54fc	Watch the mask tools work, rather than reading that they do ... A still frame cannot show what makes these tools right or wrong. What matters is how the mask *moves*: whether a stroke lands where the finger went, whether a subtraction takes away only what it covers, whether an erase inside a correction punches through the selection underneath. Every one of those is a sequence, and the test suite asserts single pixels. So this renders the sequences. A synthetic photograph, one frame per step of each mode — painting, erasing, joining a part and taking it out again, inverting, and sweeping the edge controls — as PPM, which ffmpeg turns into a GIF in one line. It runs headless, needs no RAW and no model, and takes a few seconds. It is also the honest answer to "show me it working" while the tools are still being wired to a finger: this is the pipeline itself, not a mock-up of it, and a fault in the fold shows here as a frame that looks wrong.	2026-09-07 20:00:40 +02:00
dtourolle	df741a8a49	Let one mask be built from more than one selection, and paint into it ... A mask the model draws arrives approximately right — stopping inside a shoulder, leaking into the hair — and FR-DEV-3's edge controls move the *whole* boundary, so no value of feather or dilation fixes two errors that go opposite ways. What fixes them is a second selection joined to the first, and a layer that held exactly one source had nowhere to put one. The brush the core has had all along was reachable from no control in the application. A layer is now an ordered list of parts. Each names a source and how it joins the mask before it — added to it, or taken out of it — and carries its own edge treatment, because a model's soft coverage and a stroke painted where it stopped short do not want the same feather. Invert and opacity stay on the layer, where the composed shader already reads them. The sidecar grows `[part]` blocks and nothing else. A layer of one part writes exactly the bytes it always did; a mask block with no part blocks after it reads back as one part; and a stroke, a join or a source this build cannot read costs that part rather than the layer. So every sidecar in every library still parses to the edit it always was. On the device the parts fold into the layer's one slice, so eight layers still cost eight channels: union is a `max` blend and subtraction is the erase blend the brush already used. A part is drawn into a scratch texture before it is joined, and that is not incidental — an erase stroke means a hole in *that part*, not a hole in the mask, and drawn straight onto the accumulator it would punch through the subject underneath. A layer of one part skips all of it and takes the path it always took. In the interface: a part list under the selected layer with a chip saying which way each joins, Add and Subtract beside it, a Select/Paint/Erase strip with the brush's size, hardness and flow, and a drag on the photograph that paints. Pressing Paint on a mask that cannot hold a stroke joins a part that can, rather than explaining that a subject is not a brush. A whole stroke is one step in the history. The edge controls now shape the part that is selected rather than the layer, which is the one behaviour change to an existing control: with a correction selected, the feather slider softens the correction and leaves the model's mask alone.	2026-09-07 20:00:40 +02:00
dtourolle	9ede23073d	Specify the tools that edit a mask once the model has drawn it ... The auto masks arrive in a second and cannot then be changed by a pixel: no brush, no way to cut one selection out of another, no way to drag a boundary that stopped inside a shoulder, and no way to see the alpha a layer actually produces — the canvas overlay draws what the model detected, not the mask. docs/mask-editing.md is how that closes. A layer stops holding one source and holds an ordered list of parts, each naming how it joins the mask before it, so painting on an auto mask, subtracting, and intersecting a subject with a luminance band are all one mechanism. Notes what the tree already has (the whole brush is written and reachable from no control), what the set operations actually cost (three blend states, no new texture), why the edge push is a warp rather than a local morphology, and why painting has to draw incrementally. Ends with the four decisions the build needs first.	2026-09-07 19:59:44 +02:00
dtourolle	1e171c6d31	Let a collection be picked up, rearranged, and emptied after the fact ... Collections could be made and filled and never reorganised. Nesting had a drag; un-nesting had nothing, in either direction — "All photographs" refused every drop, which is right for a photograph and wrong for a collection, which has a top level to be returned to. So a collection put inside another was in there permanently. Right-click deleted an *empty* collection outright and refused otherwise, which is wrong in both directions at once: destructive with no confirmation, and no way at all to delete a collection that held anything without emptying it by hand, child by child. And a photograph could only leave the collection the grid was scoped to, since that is the only one a button in the header can name — the cell's badge says a photograph is in three collections and never which three. Three ways in, one vocabulary: **Hold a row.** The tree is inside a Flickable, which claims any drag beginning inside it, so with a finger a drag on a row is a scroll until something says otherwise. The hold is that something. It lifts the row — drawn before anything moves, so the gesture says it has been understood — and then what the user does decides which of two things they meant: move, and it is a rearrangement; let go, and it is the row menu. The same fork the grid already uses to tell hold-to-select from drag-to-file. `decide_release` is that fork, and it is tested, because getting it wrong one way puts a sheet over every tidied tree and the other way makes the menu unreachable by touch. **The row menu.** Rename, new collection inside, move to top level, keep offline, delete. Deleting asks once when there is anything to lose and says what survives: the photographs stay in the library, and nested collections move up rather than going with it — which is what the catalog does, and what a user would never assume. An empty collection goes on the first press, because a dialogue about losing nothing is how people learn to dismiss dialogues. **"Collections…" on a selection.** Every collection the selection is filed in, each with a count — "3 of 40", so nobody takes forty photographs out of a collection thirty-seven were never in — and a way out of any of them without navigating there first. The long press used to open the offline question by itself. That question is one item in this menu now: there is one hold per row, and while it was spent on a single action nothing else the tree can do had a touch route at all. Nothing is lost — the tray on the row keeps its tap, and the question gains a full-width control in place of a 30px icon in a row shorter than the touch minimum. The row-press handler moves to `collections_ui` with the rest of what a collection row does; it lived in `library_ui` only because it opened that prompt.	2026-09-07 19:59:44 +02:00
dtourolle	577bbd82b0	Return the action the drag offered, not the one this row prefers ... Slint negotiates a drag action between source and target, and the runtime clamps whatever `can-drop` returns against the set the source allowed: an action outside it becomes `none`. Both drop targets here named a constant instead of echoing what was on offer, and each named the wrong one for half its traffic. A collection row takes two kinds of payload. Photographs come from a DragArea allowing `copy`; a collection being nested comes from one allowing `move`. The row asked for `copy` unconditionally, so images filed correctly and every collection dropped on a collection was refused — nesting by drag has never worked. The trash had the same fault mirrored: it insisted on `move` while the grid's cells allow only `copy`, so it refused every photograph dragged to it. Neither failure had anything to see. A clamped action is delivered as a refusal, which looks exactly like a target that declined on purpose, so the drag simply did nothing and left no error to search for. `decide_drop`'s Reparent branch was tested and passing throughout. It tests the decision, not the negotiation, and nothing was reaching it.	2026-09-07 19:59:44 +02:00
dtourolle	bac5801618	Ask which collections a selection is filed in, and how much of it ... `collections_for_image` answers this for one photograph and has no counts, which is enough to badge a cell and not enough to offer a removal: with forty selected and three of them in "Iceland", a sheet that says only "Iceland" invites the user to take all forty out of a collection thirty-seven were never in. `membership_of` returns the count alongside the name so the row can say "3 of 40". Chunked over the image list rather than one `IN (...)`, because the list is a selection and a select-all makes it as large as the library — past SQLite's bound-parameter cap on exactly the gesture most likely to produce it. Counts are summed across chunks, so the answer is the one the unchunked query would have given. Smart collections are excluded by construction: they have no member rows, so there is nothing a removal could do.	2026-09-07 19:59:44 +02:00
dtourolle	af89433aee	Offer the lens profile as a tick box, since applying it silently reads as absent ... The develop panel's Optics group is three manual sliders: distortion, chromatic aberration and lens vignetting. The automatic correction was already there — the file's EXIF lens is matched against the bundled Lensfun database on open and the coefficients are fanned out to all three — but nothing in the interface said so except a line of grey text under the camera reading "· corrected", and there was no way to decline it. From the outside that is indistinguishable from the feature not existing, which is how it was read. `dr-lens` states the rule this breaks: an automatic correction that silently does nothing is worse than one the user can see is unavailable. The caption satisfied the letter of it and not the point — a photographer looking for "apply the lens profile" found three sliders and no switch. So the profile is now a control. It is a capability rather than a flag on the session, because everything a photographer sets travels one road: the capability list feeds the generated panel, `Preset` captures it, the sidecar stores it and the undo stack replays it. A bool on the side would have needed adding to each of those four by hand and would have been forgotten in at least one — which is exactly how the mask stack came to be missing from the history. It is on by default, which is what `switch_on` is for: the coefficients are a measurement of the lens that took the photograph, so accepting them is neutral and declining them is the edit. The sidecar therefore stores nothing for the ordinary case and the correction still happens. The switch appears only where a profile was matched. A tick box on a photograph whose lens the database has never heard of would be a control that looks available and does nothing, which is the failure the rule above names rather than an instance of following it — those photographs are told "· no profile" in words instead, and one whose box is unticked now says "· profile off", which is a third fact and not either of the other two. Two things had to be built underneath. `ParamKind::Bool` was in the core's closed enum and mapped to a row kind here, and had no control behind it in `adjust.slint`: a parameter declaring itself a switch was flattened into a row that drew nothing at all. Nothing shipped had one until now, so the gap cost nothing and was invisible. And `Check` self-toggled, which is right for a settings page that owns its value and wrong for a panel row that is a view of the edit graph — the click would have answered by replacing the binding with a literal, and the next undo or pasted preset would have moved the value with the tick left where the finger put it. It now takes `controlled`, and the generated row uses it. The manual sliders are unchanged and still trim whatever the profile leaves, so switching it off is "correct this by hand" rather than "stop correcting".	2026-09-07 00:27:47 +02:00
dtourolle	2cd49d1cb7	Measure the rail by counting it, so it can scroll instead of clipping ... With the adjustment groups in the rail, a short window silently lost them. At a 1500x680 window the rail drew Photo, Compose, Local, Repair, the seam and "All", and then stopped: Optics, Light, Colour, Effects and Detail were not scrolled off, they were gone, with nothing on screen to say so. The develop view's primary navigation, unreachable by any means. The Flickable was put here to prevent exactly that, and it could not, because its viewport asked the layout how tall it wanted to be while the layout was already taking its height from the viewport. Slint settles that cycle by handing back the height it was given, so `max(self.height, preferred-height)` could never exceed `self.height` and there was never anything to scroll. Counting breaks the cycle. Every entry here is a fixed height by construction — a tool is `rail-entry-height`, a group is a touch target — so the content is six plus four fifty-fours plus a gap plus a touch target for each group and "All", which is exact rather than an estimate and depends on nothing that depends on it. Four tools and five groups come to 498, against the 340 a 680-pixel window leaves at 2x, and the difference is now scrollable rather than absent. Found by shrinking the window with the groups forced into the rail. The interaction itself is unverified: synthetic input does not reach a Slint window on this desktop, and the tablet was disconnected, so what is confirmed is the arithmetic and the clipping it explains, not the scrolling it should restore.	2026-09-07 00:17:08 +02:00
dtourolle	3dc7c184ee	Optimise for release only, since every edit pays for a dev build ... Dependencies were built at `opt-level = 2` even in dev, because wgpu and image decoding are slow without it. That is still true, and it is what this gives up: a debug run of the app, and the decode- and GPU-heavy tests, are slower than they were. What it buys is that nothing has to be optimised before it can be compiled. That cost was paid on every edit, in every worktree, whether or not anything was ever run — and there are sixteen worktrees, each with its own target directory and no shared cache, so it was paid sixteen times over. `[profile.release]` is untouched: `lto = "thin"` and `codegen-units = 1` still apply where the speed is actually wanted. If one crate turns out to be the one that makes a test unbearable, raise that crate alone rather than restoring the blanket rule; the manifest says how. Incremental compilation is now on as well, but that lives in `.cargo/config.toml`, which is untracked and per-checkout — so it is a local change on this machine, not part of this commit.	2026-09-06 20:17:53 +02:00
dtourolle	3f6dbce2aa	Name a lone control after its operation, so three cannot all read "Amount" ... The Detail group ended with three consecutive sliders labelled "Amount" and nothing to tell them apart. They are dehaze, clarity and texture: each declares exactly one parameter, and `ops/README.md` tells an author to reach for the `amount` kind first, so all three named it the same thing. The panel withholds a heading from a group of one, and the reasoning it gives is sound — a lone control names itself, and the group reset it loses costs nothing because the slider already resets on double-click. But that argument rests on the parameter being named after what it does. It holds for exposure, contrast, vibrance, saturation and brilliance, whose single parameter shares the operation's name, and it fails for the three whose parameter is called after its kind rather than its subject. So a lone parameter now takes its operation's label — the name the withheld heading would have carried. For the five that already agreed, nothing changes. Found on the tablet, and only there: every row was correct, every label resolved, and the panel was still unusable. The test that guards it asserts over the real chain rather than a fixture, because the fault was a property of what is actually declared — a fixture would have had to be written to reproduce it, and would then only have proved itself.	2026-09-06 19:01:54 +02:00
dtourolle	124b2d99c6	Take the first control that moves the picture, not the first one drawn ... `showing_the_original_leaves_the_edit_exactly_as_it_was` set row zero to its maximum and then asserted the photograph was modified. It was not, and the test failed on its own premise rather than on the thing it exists to check. `EditGraph::capabilities` puts the lens corrections at the head of the list, matching where they sit in the shader. Those carry profile coefficients rather than parameters, so with no profile loaded a slider on one is a control with nothing behind it: the graph stays neutral and the premise assertion fires. The test was written against a panel whose first row happened to be an adjustment, and it stopped being one. So it now walks the rows until it finds a control that actually changes the edit, which is what it meant by "row zero" all along. Still addressed by index, so it still names no operation, and it no longer depends on where in the chain the first *adjustment* happens to sit.	2026-09-06 19:01:53 +02:00
dtourolle	3994caba12	Write down the develop gestures, since only their author knew them ... FR-UI-4 says a gesture with no visible counterpart is a feature only its author knows about, and the vocabulary the application actually publishes had two sections in it — the library grid and people. Develop had none. Every one of its gestures was documented in the comment beside the `TouchArea` that implements it, which is where the previous sixteen were before this scanner existed, and unreachable to anybody not reading the source. Thirteen now carry tags: magnify by pinch or wheel, pan a magnified frame, fit and 1:1, hold to see the original, sample a neutral, undo and redo, step through the folder, reset one control, show or hide a mask layer, choose a group of adjustments, and copy and paste the settings. Each has a pointer and a touch route, so none of them is keyboard-only. Three bindings were genuinely missing and are added here rather than merely described. Ctrl+C and Ctrl+V for the settings clipboard, which the Settings panel's own comment has claimed existed for as long as the panel has and nothing bound; and [ and ] to step through the adjustment groups. 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 name one of them — stepping is the binding that survives a node being added, and "everything" is part of the cycle rather than a way out of it. Two are described and not bound. Resetting a control from the keyboard and toggling a mask layer from the keyboard both need a notion of which control or layer has focus, and the generated panel has none — the rows are a model the repeater rebuilds, and inventing a focus ring for them is a larger change than a keyboard shortcut. Both are reachable by pointer and by finger, and the tags say so rather than promising a key that is not there.	2026-09-06 19:01:52 +02:00
dtourolle	901f51e6c4	Point at something grey and let the pipeline work out the rest ... FR-DEV-3 has asked for "white balance (temperature/tint, and picker)" since it was written, and only the first half existed. `WidgetKind::WhitePoint` was in the vocabulary and `develop::supported` answered false for it, so the node degraded to two sliders — correct behaviour that had quietly become the only behaviour. Sampling a neutral is the first move of the global tonal pass and every colour judgement afterwards is measured against where the grey was put, so guessing at two sliders until a wall stops looking green is the wrong way round. The awkward part is that a picker genuinely needs to know how far a hundred units of temperature move red against blue, and that number is declared in the node's own file. So the inversion lives in `dr_pipeline::neutral` rather than in the interface: the canvas hands over a colour, the core finds the operation that asked to be driven by a pixel and bisects its declared response until the sample comes back grey. Nothing in `ui/` names white balance, and nothing holds a second copy of a response that would be wrong the first time somebody adjusted the range. A bisection rather than a closed-form inverse because only monotonicity is part of the bargain — the expression is free to become a table tomorrow. The result is rounded to the precision the control is drawn at, which is not cosmetic: unrounded, sampling something already neutral lands a ten-thousandth off zero, and the photograph comes back modified with an undo step for a correction of nothing. On the panel side this needed one distinction the generated path was missing. `is_on_canvas` was being read as "and so the panel draws nothing for it", which is right for a crop — four edge fractions are not controls anyone drags in a list — and wrong for an eyedropper, which *writes* temperature and tint and leaves them exactly the controls a photographer reaches for next. So a sampling widget keeps its sliders and puts the affordance that arms the canvas in the group's heading, built like the reset beside it. One click, one sample, one history step: `Edit::Action` never coalesces, and there is no hover preview to fill the stack with temperatures nobody chose. Declaring the presentation also groups temperature and tint under one undo step, where they were two. That follows from what `Presentation` means and reads correctly — white balance is one decision — but it is a change, and worth saying so.	2026-09-06 19:01:52 +02:00
dtourolle	2584b9ecbc	Hold one key to see the photograph before you touched it ... FR-DEV-7 asks for the current edit against the unedited original and nothing implemented it. What the develop view had was history navigation, which *changes* the edit rather than previewing against it — so the only way to look was to undo, look, and redo, and that puts two real steps on the stack at exactly the moment a photographer suspects they have overcooked a frame and is least sure of what they are doing. Holding the "Before" button, or backslash, renders the graph with every adjustment stripped and hands it straight back afterwards: the same suspend-render-restore shape the crop overlay already uses to show an uncropped frame and an export uses to suspend the zoom. Nothing is recorded, no rows are re-synced, and the photograph is still modified when the key comes up — the panel goes on describing the edit the photographer has, because only the canvas is answering a question. The framing deliberately stays on. A held comparison is a question about tone and colour, and re-cropping the canvas under someone's thumb would move the detail they are comparing; worse, the zoom is a rectangle of the *framed* image, so dropping the crop at 4× would quietly show a different part of the photograph rather than the same part unedited. What the crop took away is already compared in Compose, which shows the whole frame. Not a split screen: that halves the working image on the tablet this column was sized for, and the comparison photographers describe making is a flick back and forth rather than two pictures side by side. Press-and-hold is one gesture on a finger and on a mouse, which is what FR-DEV-3b's mapping wants, and it has no mode to be stranded in — the button reports both edges, so a press the system cancels puts the original down too.	2026-09-06 19:01:51 +02:00
dtourolle	9b674a88d8	Let the photographer look at the pixels, and keep looking ... Noise reduction and capture sharpening are judgements about individual pixels, and at a fitted view several of the file's pixels are averaged into each one on screen. The frame therefore looks cleaner and softer than it is, the photographer corrects for a softness the display invented, and over-sharpening is the documented result. Nothing in the develop view reached 1:1 at all: the wheel and the pinch zoom by ratios, the double tap dropped straight to fit, and the only readout was a percentage nobody was aiming at. So the double tap now does what FR-UI-4 always said it did — toggle fit and 1:1 — and the zoom readout, which used to be a dead "Fit" button on a fitted photograph, becomes the way in when there is nothing to clear. Z does the same from the keyboard, and the back gesture goes out through the same toggle so putting the magnifier down really puts it down. 1:1 is computed from the file's own resolution against the viewport rather than fixed at some multiple, because that is the only version of it that answers the question the two detail controls are asking. The point being inspected and whether the magnifier is up are held beside the session rather than in it, on the argument focus peaking already makes: a session is one photograph and this is a way of looking at a folder of them. Checking the same eye across forty portraits is the reason to reach 1:1 in the first place, and a magnification that reset with the session would make that forty zooms and forty pans instead of forty keystrokes. It stays a viewing state throughout — the view is kept out of `is_active`, `output_size`, the sidecar and the export, and an export still suspends it — so none of this reaches the file.	2026-09-06 19:01:50 +02:00
dtourolle	43652bd613	Say where the positives really come from, not where they were going to ... `calibrate.rs` claimed its positive pairs came from user confirmations "then burst siblings, since FR-CULL-5 already groups bursts", and repeated it beside the pair floor: "the positives are bootstrapped from bursts and a handful of early confirmations". Neither is true and neither ever has been. Nothing in the workspace pushes a burst pair into a `Pairs`; nothing pushes any pair at all outside this file's own tests. The sentence was written while both halves of docs/faces.md §8.1 were being planned together, describing a source that was going to exist, and it has read since as a description of what the code does. The distinction matters more here than in most comments, because this file is the one place in the subsystem allowed to say what a similarity *means*. A reader who believes the fit is drawing on bursts believes a young library is gathering positives on its own, which is precisely the opposite of the state FR-CULL-9 legislates for — a library with no fit, no valid calibration, and a reference curve it must not present as a measurement of itself. The floor of 200 positive pairs looks arbitrary under the wrong story and obvious under the right one: confirmations arrive one at a time, from a person. So the comment now says what is here — a positive is a pair confirmed onto one person, and there is no second source — and keeps the burst idea where it belongs, as §8.1's proposal, with the two reasons it is not in the code: this crate is handed cosines and cannot see a catalog, and the purity of a burst pair is a thing to measure before it is a thing to trust. No behaviour changes; the arithmetic is untouched.	2026-09-06 19:01:50 +02:00