mirror of
https://github.com/storytold/photocraft.git
synced 2026-10-29 04:17:11 -06:00
Ahmed Hosny
c25630b5fa
* app.save: encode on the save worker, not the UI thread (#2488) The automation save ran export+write inline inside the control drain, freezing the window and every queued control request while a large document encoded — and overrunning the 60s reply deadline. It now uses the same #2017 background path as File > Save when background jobs are on: the encode and the capability-scoped write run on a worker, the document is locked, and the control reply waits on the job (wait: false answers {job, pending} at once). Tests and the web keep the inline path. The save job's result now carries the path alongside the warnings, so waiting callers get the same {path, warnings} reply both ways. * app.save: never fire saveDocument hooks from automation saves; review fixes (#2488) Automation saves complete in the job tick, long after run_waiting lifted its synchronous event suppression, so the background branch fired the user's saveDocument script bindings and Image Assets — the exact hooks docs/control-protocol.md promises never run for automation. SaveJob now carries an automation flag and records through saved_automation, which skips document_saved on every path; the inline fallback records through it too, so both modes behave the same. A regression test installs a saveDocument binding and asserts it fires for an interactive save and not for app.save. The desktop's two save workers collapse into one save_through parameterized by the write step (drift between interactive and automation saves), the Saved status/notices are translated (Saved {name}, 16 locales), the pending reply carries warnings like file.save's, and the success payload is built at one site.