How OpenChronology was built

#181 · Bulk edits for large desktop files: shift or scale times, delete a view

2026-10-16T13:57:34Z CE

• timeline-app
• pull request
• packages

Closes #179. **Shift or scale times…** (#96) and **Delete everything in this view…** (#91) now work in desktop `.och` files over 2,048 moments, which the app keeps in its native SQLite store rather than the page. ## Why native In those files each unsaved edit is an overlay in the page: drawn as its own marker, and checked against every summary on every frame. A bulk change of tens of thousands of moments as overlay edits would make views unusable. So the change is made natively instead. ## How it works - **`desktop_stage_patch`** (Tauri) applies the change to a *patched copy* of the baseline (`Snapshot::with_patch` in `native-store`), reporting progress through a Tauri channel to the dialog's progress bar. - The copy becomes the open baseline, **unsaved**: the file on disk is untouched until **Save**. - The copy gets a new save token, so the next save writes the whole file (the existing `save_patch` fallback). Saves after that apply in place again. - **Undo and Redo** switch back and forth between the kept baselines (`desktop_restore_baseline`, up to eight kept) until the file is saved or another is opened. Desktop saves already clear the undo history. - **Unsaved edits:** both the change and its undo need no other unsaved edits (overlay or settings), which swapping the baseline would lose. The dialog then says "Save your changes first", as the server path does. - **The dialogs say ahead what happens:** - "It changes the file's copy at once; you can undo it until you save the file." - "You can undo this until you save the file." ## Tests - **Native** (`staged_patches_leave_the_baseline_and_file_until_saved_whole`): - staging 5,000 changes leaves the original baseline and the file untouched; - progress is reported; - views read the new baseline; - a save with no other changes writes the whole file (durations that follow moments preserved); - the next save applies in place again. - **`test/desktop-bulk.mjs`**, the real app through tauri-driver with a 5,000-moment file in the native store: - shift what is tagged, then undo, redo and undo; - delete a view, then undo (the duration comes back too); - refused with an unsaved title change. It runs in the "Desktop app / UI interactions" CI job, before the benchmarks, so a budget flake can't skip it. - **Locally:** native-store 24 tests, src-tauri 4, 272 unit tests, typecheck, Prettier, and all 11 browser suites pass. **Not covered by an automated test:** pressing **Save** in the app after a staged change. The test's file is an import with no path, so Save opens a native file dialog WebDriver can't drive. The native test covers the save itself. **Local note:** in this VM, WebKitGTK drew nothing under Xvfb until `WEBKIT_DISABLE_DMABUF_RENDERER=1 WEBKIT_DISABLE_COMPOSITING_MODE=1` were set; the same happened on main. CI's runners don't need them. The test's header mentions it.

Open #181 · Bulk edits for large desktop files: shift or scale times, delete a view in the timeline