mirror of
https://github.com/storytold/figcraft.git
synced 2026-10-24 10:27:00 -06:00
bflatastic
01bc5a9dac
- **Installed plugins survive a crash.** Importing, installing, updating or removing a plugin, and a plugin changing its settings, now sets `Runtime::unsaved`; at the end of each frame the app hands the preferences to a new `Services::save_prefs`, and the desktop app writes `state.json` at once (temporary file + rename, the same atomic write the quit path uses, now shared). Nothing waits for quit any more. - **The UI never waits on the network.** New `Session::start_background(id, params)`: the command runs as usual until it makes a server request; the request goes out on the link's own thread (`LiveLink::background`, implemented by the desktop `NetLink` with one short-lived thread per request) and the command stops; when the answer arrives (`Event::Net`, taken by `live_poll`, which the network's waker already triggers) the command runs again from the start on the file it started on, answered from the answers so far, until it needs no new request. All server requests go through one funnel (`Session::net`), so `plugin.directory.*`, `library.publishToServer`, `library.add` (links), `library.usage` and library fetches work this way without being split. A re-run of `library.publishToServer` caches the library it actually sent (a fresh copy differs in its time and, on a first publish, its id). One job per command; `cancel_background` drops a late answer. - **UI:** `FigApp::run_background(ctx, id, params, done)` with a boxed completion. Manage plugins > Browse shows "Fetching from the server..." with Cancel instead of Browse; the install confirmation shows "Installing..." with Cancel and stays open until the download is in (an error leaves it open to retry); row buttons wait during an install; closing the window cancels. Assets > Libraries: Publish to server shows "Publishing..." + Cancel, Show usage and pasting a team library link show "Fetching from the server..." + Cancel. No polling repaints: the window draws again when the answer's waker fires; pending state is a scan of a short Vec, no per-frame allocation. - **Programmatic callers are unchanged:** MCP, CLI, control channel and scripts still run the same commands synchronously (and the browser link, which has no background requests, too). - New string "Installing..." (en/es); docs: plugins.md (immediate saves, Browse/Install never wait), server.md (team library requests never wait).