28 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	e957d483fc	Give the film list a scrollbar on the desktop ... A list cut off at its edge looks, to a mouse, like a list that ends there. The open film list shows ten rows of twenty-eight, and nothing said there were more. The user asked for visible scrollbars on every platform but Android. ScrollBar (widgets.slint) is a vertical bar drawn over a Flickable's right-hand edge. It shows the share on screen and the position, it can be dragged by the thumb from wherever it was grabbed, a click on the track moves a page toward the click, and the wheel over it scrolls. It is the Flickable's sibling rather than a wrapper, bound to `viewport-y <=> flick.viewport-y` and the two heights, so a scroller keeps its own sizing. It is drawn over the content rather than beside it, so the mandated column widths are not reduced. With nothing to scroll it is not drawn and takes no input. Whether to draw it is Scrolling.bars, which Rust sets from dr_plat::is_touch_first(). That is the same function that puts the develop groups in the rail, and it answers the same question: what is the user pointing with? On Android, lists still scroll by flick only. Placing the bar inside another scroller would put it back in that scroller's arbitration. The film list can have one because it is now a popup.	2026-09-26 07:24:45 -04:00
dtourolle	80938b0527	Open the film list as a popup, so every stock can be scrolled to ... The open stock list showed ten rows, None to Kodak Kodachrome 64, and the other eighteen - all seven black-and-white stocks among them - could not be reached. The data was whole; the list could not be scrolled. Reproduced on the manual rig (Xvfb, xdotool, the automation hook): - a drag on the list scrolled the develop column, never the list; - a wheel run over the list scrolled the column past it, whenever the column had scrolled under that pointer in the last 800 ms - which is how the list is reached, by wheeling the column down to it. After a pause and a pointer move the wheel did reach the list; - no key did anything. The cause is Slint's routing, not the list. Since 2d878c2 the list was a Flickable inside the develop column's Flickable, and Slint offers every pointer event to the outermost Flickable first (input_event_filter_before_children, i-slint-core 1.17.1 flickable.rs). The column holds a press back (DelayForwarding) and intercepts the first move past 8 px on the axis it can scroll, so the list never saw a drag. For the wheel it intercepts while its own last wheel event is under 800 ms old and within 2 px, and always for a touchpad gesture that opens with TouchPhase::Started - so on a touchpad the list could get no wheel at all. The list is now a PopupWindow under the Film row. A popup is its own item tree: while it is open, events go to it and to nothing beneath it, so the list scrolls by wheel, drag and flick however the panel is nested and whatever the column did last. The alternative, standing the column down while the pointer is over the list (the sliders' hover trick), fixes the drag but not the wheel - `interactive: false` does not gate wheel interception - so it would have left the bug for touchpad users. The reason 2d878c2 bounded the list still holds: it is at most 320 px and never lengthens the column, and now it covers the sliders instead of pushing them down. The column cannot be scrolled while it is open, which suits a one-click question; it closes on choosing, on Escape or Back, or on a press outside it. Keys, with the list open: Up and Down move along it from the chosen stock and scroll it into view, Enter chooses, Escape or Back closes it unchanged. A popup is its own focus tree, so the keys are taken when it opens and Slint returns focus to the develop view's scope when it closes. The Film row gains a button role, so a screen reader and the automation hook can name it.	2026-09-26 07:24:28 -04:00
dtourolle	6640ce0ca8	Regenerate the matrix, the gesture book and the manual page for the duplicates review	2026-09-26 07:20:19 -04:00
dtourolle	380cfda695	Make develop's Help a "?" beside Settings, so Settings fits at 1600 ... Adding a labelled Help button to develop's top bar made the strip about 100 pixels wider than a 1600-pixel window. The strip scrolls, so nothing became unreachable, but Settings was off the right-hand end until the bar was dragged. Help is now a square IconButton with a drawn question mark (a new "help" icon, drawn rather than typed for the reason icons.slint gives about Android's fonts), and screen readers still hear it as "Help". That saves 60 pixels, which was not enough alone: the strip had fit with 3 to spare before. The rest comes from the spacing. Controls that belong together now sit in groups at gap-sm with gap between groups: Pick and Reject, Undo and Redo, Copy, Paste and Presets, and "?" and Settings. The empty export-status caption no longer takes a slot and two spacings while it has nothing to say. At 1600 wide with the panel open the whole bar now shows, Settings included. The grid's header keeps its worded Help button; it has room for it. The develop "Open this list" gesture now names the "?" button, and the gesture book is regenerated from it.	2026-09-25 23:24:52 -04:00
dtourolle	d9f259656a	Open Help from develop as well as from the grid ... The "Controls and shortcuts" sheet was drawn by LibraryGrid, so only the grid's Help button and its F1 could open it. Develop, where most of the keys it lists are bound (Ctrl+E, Ctrl+Shift+C, A/D, Z, R, H, [ ]), had no way to it: a photographer who wanted to look a shortcut up had to leave the photograph they wanted it for. The sheet now hangs off the shell beside the export and copy sheets, on a `help-open` property both views set. The grid's Help button and F1 raise it through a callback, and its keys stand down through the `sheet-open` they already honour for the export sheet, so Escape falls through to the shell, which closes it. Develop gains a Help button beside Settings in its top bar, as in the library header, and F1 in its key scope; its keys decline while the sheet is up, as they do for the other two sheets, so nothing behind it is rated or stepped. The book already begins with the Develop section, so from develop it opens where the reader wants it. Tests hold the shape: the sheet is drawn by the shell and not the grid, and develop's opening guard names all three sheets and its F1 opens this one. The new GESTURE: block puts the develop route in the book.	2026-09-25 23:24:52 -04:00
dtourolle	f8737e3fda	Close the help sheet with Escape, and keep keys from acting behind it ... F1 opens the help sheet from the grid, and nothing on the keyboard closed it: Escape fell through to the shell, and every other key went on judging, labelling and keywording the photographs hidden behind the sheet. Escape and Back now close the sheet first, ahead of the grid's other sheets, since it is drawn over all of them. While it is open the grid's handler declines every other key, so a stray P or Ctrl+K changes nothing the reader cannot see.	2026-09-24 23:42:27 -04:00
dtourolle	d489a34190	Drive develop, the grid, the sidebar and People from the keyboard ... An audit of every action by view against the keys the handlers bind left develop without zoom, pan, fit or a way back to the grid, the grid without select-none, thumbnail size or keywording, People with no key at all, and the export and copy sheets without Enter. It also found the reverse gap FR-UI-5 forbids: pick and reject had no route but P, X and U, and the 2026-09-19 amendment's judging in develop had not been built. Develop: Ctrl+= and Ctrl+Plus zoom in and Ctrl+- out about the middle of the view, Ctrl+0 fits and Ctrl+1 goes to 1:1, Shift and an arrow pan a magnified view, G goes back to the grid, Ctrl+Y redoes, and Enter keeps a crop that hid a mask. 0-5, P, X and U rate and flag the open photograph without moving on, with stars and Pick/Reject in the top bar as the pointer and touch route. = and - nudge the control last moved by a hundredth of its travel; the framing sliders, perspective included, now count as "last moved", so R puts them back as well. J turns the selected mask part's join chip. Grid: Ctrl+D and Ctrl+Shift+A clear the selection, = and - resize the thumbnails, Ctrl+K opens keywording, and Flag in the selection bar gives pick and reject a pointer and touch route. Sidebar: Enter commits a collection's name, and Enter or Escape hands the keyboard back to the grid, where it used to go nowhere until something was clicked. People: Up and Down walk the rail, F2 puts the name field under the keys, and Escape or Back now leave the screen the way its back button does instead of doing nothing. Sheets: Enter does what the export or copy sheet's button does. The choices follow Lightroom where it has one. No new key steals typing: the grid's and People's keys live on focus holders that are not ancestors of any text field, and the sheets' Enter comes after a focused field has had it. Every binding is tagged beside its handler, and the gate added in the previous commit holds the two to each other.	2026-09-24 23:42:26 -04:00
dtourolle	9d1e31ffbb	Fail CI when a key is bound but not in the gesture book, or listed but not bound ... The gesture book is generated from GESTURE tags, so it could not describe a gesture nobody tagged, but nothing made anyone tag one. The arrow keys, Enter, P, X, U, Delete, F1 and F2 all worked in the grid with no line in the help sheet, and a tag could name a key whose handler had gone. Key handlers now compare one canonical string, Keys.chord(event) == "Ctrl+Z", instead of reading event.text and the modifiers themselves. keys.slint folds the key and its modifiers into that spelling, so the literal in the handler is the whole binding and the checker reads exactly what the handler dispatches on. Each handler carries a KEYMAP comment naming the gesture-book section its keys belong to, and a tag's keys field names its keys between backticks. gestures-check now fails when a handler binds a key no tag in that section names, when a tag names a key no handler there binds, when any .slint file other than keys.slint reads event.text, when a compared literal is not canonical, and when keys.slint's named keys drift from the Rust list. Spellings are normalised in one place, chord.rs: Ctrl+z, Control+Z and LeftArrow all mean what the handler's "Ctrl+Z" and "Left" mean. Shift and Alt count only for letters and named keys, because on the French layout every digit needs shift and a 6 has to be a 6 however it was typed. A Rust keymap that both dispatched and was read by the generator was the alternative. It would have moved the handlers' decisions away from the Slint state they depend on, and a window that forgot to install it would have had no working keys at all. The keys that were already bound and undocumented are now tagged.	2026-09-24 23:42:25 -04:00
dtourolle	150e53e878	Link fifty gestures on the help sheet to the manual section that shows them ... The sheet could now offer "See it", but no gesture said where to look. Every GESTURE tag whose move the manual describes names that section: the white-balance picker, zoom and pan, masks, undo and snapshots, export, colour labels and ratings, selection, collections, the People page, thumbnail size. Fifty of the fifty-one; the one left, putting a single control back to its default, has no section and is too small to earn one. Three important gestures had nowhere to land, so the manual gains three short sections, without pictures for now: Bursts (opening a folded burst, choosing the frame it shows, and the eyes-open filter), Moving between photographs (the roll, the arrows and A/D in develop) and Copying settings (Copy, Paste, Paste to N, and choosing what a copy carries). The page, the gesture book and docs/gestures.md are regenerated from them.	2026-09-24 23:25:37 -04:00
dtourolle	7591738c73	Let a gesture name the manual section that shows it ... The help sheet says which move does a thing, and the manual has a picture of the thing being done, but nothing joined the two: a user reading "Pinch it with two fingers" had no way from there to the GIF of it. A GESTURE tag takes an optional `manual:` field naming a heading of docs/manual/README.md by its anchor. The scan checks every one against the anchors the bundled page is rendered with and fails when the manual has no such heading, so renaming a section cannot leave the sheet linking to the top of the page; gestures-check carries the same failure into CI. The anchor goes into gesture_book.rs as a new field, and into docs/gestures.md as a "See it" link to manual/README.md#anchor. The help sheet draws a "See it" button beside the title of each gesture that has one, which opens the bundled manual at that section. The field is additive: a tag without it is unchanged, and no gesture carries one yet.	2026-09-24 23:24:17 -04:00
dtourolle	46f5b95828	Show and set colour labels in the grid and develop, and filter by them ... Colour labels could be read from a Lightroom sidecar and queried by the selector, but nothing drew one or set one, so the only labels a library held were ones another program had written. Every mark carries its label's initial on its colour — R, Y, G, B, P — so a label is read without telling red from green, which is what NFR-A11Y-3 asks of colour labels by name. A grid cell shows the mark before its filename. In the grid, 6, 7, 8 and 9 set red, yellow, green and blue as Lightroom's keys do, on the photograph under the pointer or on the selection by the rule the star keys follow; the same key again takes the label off, and over a mixed selection it sets it on all. The selection bar gains Label, which opens the six choices — each a mark and a name — and purple, which has no key, is there. In develop the top bar says "Label: Green" beside the mark, opens the same choices, and 6-9 label the open photograph. Each gesture is one catalog transaction, then the grid, the counts and both sidecars are written as a rating's are. The filter bar gains a chip per label, its mark and its name with a count, one at a time; the filter is one SQL term, travels in the place record, and "All" clears it.	2026-09-24 21:52:23 -04:00
dtourolle	8cdad3863d	Keep only where two selections agree, as a third way to join a mask part ... A layer's parts could be added to the mask or taken out of it, and nothing else. The selections that need composing most are the ones that are neither: the sky that is also bright, the subject that is also skin. With union and subtract alone, "this and that" had to be spelled as "this minus everything that is not that", which needs a second part that selects the complement and rarely exists. Join gains Intersect, stored as "intersect" in the part block of a sidecar. It is the product of the two coverages, dst * src, which is one more fixed-function blend state beside union's max and subtract's dst * (1 - src) (mask-editing.md 5.2): the same scratch texture, the same three vertices, no shader arithmetic. The product equals the minimum wherever either side is fully in or out, and is the softer reading where two soft edges overlap. Join::apply spells the three operations on the CPU so the GPU tests can be held to one definition. A layer that intersects with a part covering nothing now reports that it covers nothing, so it is not rasterised as an empty slice. Old sidecars never contain the word, so they read as before; a build from before this reads "intersect" as a union, the existing unknown-join fallback, which keeps the part visible rather than dropping it. Join::ALL keeps union and subtract at indices 0 and 1 so a stored panel index still means the same join.	2026-09-24 21:25:48 -04:00
dtourolle	00c028c8c8	Rate under the pointer, filter a star range, and name Help as help ... Rating keys in the grid follow darktable's rule: with the pointer over a photograph outside the selection, 0-5, P, X and U judge that photograph alone; over one inside it, the whole selection, as before; off the grid, the selection. The hover is cleared when the grid scrolls, so a key after a wheel turn cannot judge whatever used to be under the pointer. Holding F and tapping digits filters by stars: one digit for exactly that many, two for everything between them, F alone to show every rating again. The filter gains a ceiling to do it (`max_rating`, one BETWEEN in the query). The place record carries it, and a record from an older build reads as having none. The star chips light across a capped range and the bar says "2-3★ only" beside them. The grid also takes Ctrl+E and Ctrl+Shift+E for the selection, Ctrl+V to paste onto it and Ctrl+A to select all. The "Gestures" button is now "Help", its sheet "Controls and shortcuts", and F1 opens it.	2026-09-24 05:11:36 +02:00
dtourolle	bddf3250c5	Add Lightroom's export and copy shortcuts to develop ... Ctrl+E opens an export sheet: the export defaults on their own, over the photograph, with an Export button. Ctrl+Shift+E exports straight away on those defaults. There is no per-export copy of the settings, so what is chosen in the sheet is saved as it is on the settings page, and the next Ctrl+Shift+E uses it. To make that one set of controls in two places, the export options move out of the settings page into export.slint: an `ExportOptions` global that Rust writes once, and two panels that read it. The window no longer forwards forty `settings-*` properties to the page. Ctrl+Shift+C opens a copy sheet with the edit-kind chips the preset sheet already uses and a Copy button, which is how a paste leaves each photograph's crop and rotation alone (Compose off). A and D step along the roll beside the arrows. While either sheet is up the develop keys stand down, so A cannot change the photograph behind the form, and Escape closes it.	2026-09-24 05:11:16 +02:00
dtourolle	9ebaa15099	Move copy, paste and presets into the develop top bar ... They sat in the develop column under a "SETTINGS" heading, which read as application settings, and went away with the panel toggle and in the mask and spot modes. The strip is where undo already is for the same reason: these act on the whole edit, not on any one panel. The paste button still names what it would apply. The TransferPanel component is gone; the Transfer global and its Rust wiring are unchanged.	2026-09-22 21:37:31 -04:00
dtourolle	83f4253b6a	Filter the grid to a person with their eyes open ... An "Eyes open" chip beside the people chips, offered only while someone is chosen and dropped when the last person goes, so no term narrows the grid with nothing on the bar to say so. It compiles the rule in dr_face::eyes into the person's face subquery — Anna, eyes open, whoever else is blinking beside her — and drops a frame only on a closed eye that could be read: sunglasses, eyes too small or soft to read, and faces never read all pass, so an old library shows everything under the chip until the measuring pass has run. A test drives the same readings through the SQL and through the rule and requires them to agree. The People screen badges a face "Eyes closed", "Sunglasses" or "Eyes unclear" so the reason a frame is or is not in the grid can be read off the face; the sweep loads the three models when they are beside the pair and reads eyes on the indexing and measuring passes from the native render; the coverage line counts unread faces as work to measure so an already-indexed library keeps its Index button. The term travels with the place.	2026-09-19 14:04:35 +02:00
dtourolle	d3b6127db6	Let a photographer name the state they liked, and go back to it or look at it ... FR-DEV-5 asked for named snapshots of an edit state and FR-DEV-7 for a comparison against a chosen one, and neither existed. The history stack is per sitting and forgotten with it, on purpose — the gap that mattered was an automatically saved mis-drag with no way back, and that was closed first. What was left was the other half: a state the photographer wants to keep *because* it is worth keeping, which is a different thing from a step and is not served by making the steps last longer. A snapshot is an edit state, and an edit state is exactly what a sidecar version stores, so it is stored as one: a `[version]` block carrying `snapshot-of = <uuid>`. The parameters, the masks and their parts, the repairs and the film all arrive through the blocks that already carry them, a merge keys on the uuid as it does for any version, and a build that predates the key reads the block as a named version and keeps it — the right failure. Only the pointer is new. The one reader that has to know is `default_version`, which must never answer with a snapshot: a file whose edit is missing is not a file whose edit is one of its saved moments. The snapshots of an edit are listed by that pointer, oldest first, the same on every device. Writing them back removes what this sitting deleted and puts in what it holds, and leaves standing whatever it never saw — a snapshot the other device took since the photograph was opened here is not this device's to remove by not knowing about it. That is the rule the version merge already keeps, applied one level down, and it is why the save carries the deleted ids rather than replacing the list wholesale as the masks are. Each is re-pointed at the uuid the save settled on, because the default may have been fused onto its canonical identity since the snapshot was taken. Restoring is one history step, so undo takes it back whole, as a paste is. Taking and deleting are not steps: they change nothing about the photograph, and an undo that removed a snapshot would be undoing a decision to remember. Holding the eye beside one renders the snapshot and hands the edit straight back — the same suspension "Before" uses, against a point the photographer chose rather than the file. Two sessions on the same photograph get ids that cannot collide, stamped with the second and a random word, because the merge folds equal ids into one.	2026-09-12 01:08:10 +02:00
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	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	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	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	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	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	1c5c55b4c9	Let the photographer say which frame the burst stands for ... `choose_representative` has been in the catalog since the grouping landed, with tests behind it and nothing calling it. So the frame a folded burst drew was always the earliest one, and the only way to disagree was to open the group and leave it open — which is to say there was no way to disagree at all, because a burst that stays open is a burst that was never collapsed. The earliest frame is the right default and it is deliberately not a judgement: nothing here scores a photograph, and FR-CULL-5 names the failure that rule avoids. But the whole point of a burst is that one of the twelve is better than the other eleven, and the person who knows which is the one looking at them. So a ring on each frame of an open group, ticked on the one the group folds to. It is drawn only while the burst is open, because that is the one moment the alternatives are on screen to be compared — offering the choice on a folded burst would be asking about frames it is hiding. Bottom right, opposite the count in the other corner, clear of the flag and the collection badge and, deliberately, of the trash target: a slip between the ring and the fifth star sets a rating, which is the harmless direction for an ambiguous press. The mark stays live on the frame that already wears it. A disabled TouchArea would let the press fall through to the cell behind it, so tapping the one ring that is ticked would have opened the photograph — and pressing it is a thing the user may mean anyway: it records the choice the default was making silently, which then survives a regroup that finds an earlier frame. Choosing repaints the badges instead of reloading the window, which is what separates it from folding a group up. Folding changes what the grid's query returns; this changes only which cell wears the tick, and the tick has to leave the frame that was carrying it, so the whole window is refilled in the one statement `sync_badges` already runs. The gesture is documented where FR-UI-4 requires it to be documented: in a tagged comment beside the control, which is the only copy. The gesture book, the gesture document and the requirements matrix are regenerated from the tree alongside it.	2026-09-06 19:01:49 +02:00
dtourolleandClaude Opus 5	b34e786f01	Give the drag a pick-up, so it stops losing to the scroll ... Dragging a photograph out of the grid worked about half the time, and nothing on the screen explained the other half. `DragArea` and `Flickable` do arbitrate, but not evenly. The Flickable claims any press that travels more than eight pixels along its own axis within half a second of landing, and holds that claim until the finger lifts. So a drag toward the sidebar only ever began two ways: a flick sideways clean enough that the finger never wandered eight pixels vertically, or a wait of half a second before moving at all. Both are real gestures and neither was written down. The wait is now the gesture, and it has a mark. The long press that already turns on selection mode also picks the photograph up: a ring opens around the cell and the grid stops scrolling under it, so from that moment the drag is the only thing the finger can be doing. The cue can only arrive after the ambiguity has passed, which is the right way round — when the photograph lifts, dragging it works. Two details worth naming. The hold is now armed even when selection mode is already on; it used to be skipped there, on the grounds that there was no mode left to switch on — but that is precisely the state a forty-image drag starts from, so the one gesture that most needed a pick-up was the one with none. And the ring is drawn after the cell loop rather than on the cell: z-order inside a `for` is loop order, so a cell grown past its bounds would stand over two neighbours and be cut off by the other two. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-30 13:20:56 +02:00
dtourolleandClaude Opus 5	b120ce48ec	Float the selection bar over the grid instead of above it ... Selecting the first photograph inserted a 40px row into the view's vertical flow, so every cell in the grid moved down by it. The act of selecting shifted the thing being selected out from under the finger — and a second tap aimed at the neighbour landed on the row below it, which is the worst possible response to a gesture whose whole job is to say "this one". The bar is a floating one now, at the foot of the view. Nothing above it is re-laid out, so selecting changes what is drawn and never where. The grid's viewport grows by the same 40px while the bar is there rather than the Flickable shrinking, which is what keeps that change invisible too: every cell stays exactly where it was and there is simply further to scroll, so the last row can be brought clear of the bar instead of being trapped under it. It also swallows presses that land on it. A bar floating over the grid is a bar a thumb can reach for and miss into. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-30 09:47:20 +02:00
dtourolleandClaude Opus 5	31a3580f9d	Extract the gesture vocabulary from the code that implements it ... Every gesture the application has was documented in the comment beside the `TouchArea` that implements it. Excellent comments, and unreachable by anyone not reading the source — which is the FR-UI-4 failure in a different costume: a gesture nobody can find is a feature only its author knows about. Writing them out again in a hand-kept help page is the failure this avoids. Two descriptions of one gesture drift, and it is always the prose that drifts: the code is exercised every time somebody uses the application and the page is exercised never. A help screen confidently describing a double tap the grid stopped honouring last week is worse than no help screen — and the grid did stop honouring one, in the commit before this. So the comment beside the implementation stays the only copy, and a `GESTURE:` block beside it is scanned into two artefacts: `docs/gestures.md` for a reader, and a Rust table for the application to draw a help sheet from. Both committed, both gated, so neither can quietly stop describing the code. It lives in the traceability crate because it is the same operation on the same input — walk the tree, pull structured tags out of comments, render, fail if the committed artefact has moved. Only the vocabulary is new. It scans `ui` and `apps` alone: a gesture needs an interface to be performed on, and excluding `tools` is also what stops the scanner extracting its own worked examples as broken gestures. Fifteen gestures so far, across the library grid and the People screen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-30 00:09:49 +02:00