• DarkRoom 0.19.4
    Benchmarks / Frame budget (on demand) (push) Canceled after 0s
    Benchmarks / CPU and I/O (per commit) (push) Canceled after 5s
    Traceability / Requirement traces (push) Canceled after 0s
    Build and test / Desktop (Linux) (push) Successful in 1h21m7s
    Build and test / Layer separation (push) Successful in 46s
    🐳 Android image / Build and push (push) Successful in 4s
    Build and test / android-image (push) Successful in 5s
    🐳 Windows image / Build and push (push) Successful in 1s
    Build and test / windows-image (push) Successful in 2s
    Build and test / Android (aarch64) (push) Successful in 47m42s
    Build and test / Windows (x86_64, cross) (push) Successful in 54m42s
    Build and test / Publish the release (push) Successful in 52s
    Stable

    dtourolle released this 2026-10-03 01:42:17 +00:00 | 89 commits to master since this release

    A bug-fix release: exports to the server respect the "when the name is taken" setting, and stepping through photographs in develop no longer flashes the wrong picture.

    Exports to Nextcloud no longer overwrite files of the same name. An export bound for a server album is queued on the device first, and the queue could not see the server, so every export uploaded under the name it was given and replaced any file already there. "Add a number" and "Skip" behaved like "Replace". The upload now checks the album's folder before sending: "Add a number" saves as name-1.jpg, name-2.jpg and so on, and the album keeps track of the name each file got; "Skip" leaves the existing file alone. Two exports of the same name queued before either had uploaded no longer end up as one file. Exports already waiting in the queue from an earlier version upload under their original name, as before.

    Stepping to the next photograph shows it once. Moving along the roll in develop could show up to four pictures in turn: the thumbnail, the previous photograph again, the new one without its edit, and finally the edited result. The thumbnail now stays up until the new photograph's first frame is drawn, and that frame waits briefly for the stored edit, so it appears with its edit already applied.

    An edit no longer lands on the wrong photograph. If a photograph's stored edit arrived after you had already stepped to the next one, it was applied to the next one. It is now discarded once you have moved on.

    The catalog's schema is unchanged, so tablet and desktop can be updated in either order.

    The APK, the desktop binary, the Windows installer and SHA256SUMS are built by CI from this tag's commit.

    Downloads