Videola 0.6.0 — it updates itself, and it goes vertical
Updates on both sides, a download page that knows which system you are on, a shape change for
vertical cuts, freeze frames, and the browser build as an installable, offline-capable application.
New
- Downloads that find you. The download page works
out which system is asking, offers that build first and lists the others with their sizes. The list
is read from the latest release at load time, because a page that spelled out file names would go
on offering last spring's build months later. Sizes in the reader's own notation — 7,3 MB on the
German page, 7.3 on the English one. Android and iOS say that they are missing from a release and
why: they exist only where a signing key does. - The browser build updates itself. A tab left open for a week used to run whatever was current
when it was opened. A service worker now notices a new build: the new worker installs beside the
running one and waits, the editor offers a reload, and the swap happens on that reload. Nothing is
exchanged under a running session —clients.claim()is deliberately absent. - And it installs, and works offline. A manifest makes it an application on the desktop or the
home screen; the same worker serves it without a network. Two caching rules and both follow from
how Vite names what it builds: a name carrying a content hash can never change, so it comes from
the cache; everything else, the document above all, goes to the network first, because that is the
request which tells the browser a new build exists. - A real update dialogue on the desktop. Which version, a button, and a bar that reports how far
the download has got — or goes indeterminate where the host reports bytes with no total, because a
bar that invented a number would lie about how long this takes. It cannot be dismissed mid-download,
and a failure says the version in hand keeps working. (The updater still needs a signing key on the
release; without one a build carries no updater configuration at all.) - Change shape. Portrait, square or 4:5 in one press, with every clip scaled to cover the new
frame in the same step. The factor applies to what the author already chose, and placement scales by
the axis it is measured on, so a lower third stays a lower third instead of ending up 1080 pixels
from the middle of a taller frame. - Freeze frames. Two cuts and a rate of zero — the core has always meant a frame hold by that.
The piece after the freeze is slipped back by the held duration, because the held piece consumed no
source: without that, a freeze puts a jump at its own end. - A transition on every cut. A slideshow is fifty pictures and forty-nine dissolves. One choice
dresses every cut where two clips actually meet, and its first entry takes them all away again. - Overshoot in the curve field. The field now reaches a third past the unit square at each end,
which is what makes a bounce authorable: a handle above where the travel arrives sends the value
past its destination and back. Two firmer lines mark where the travel sets off and arrives, and the
unit square is kept square so the dashed diagonal is still a diagonal. - One easing on the whole track, paste attributes from the clip on the clipboard, an about
dialogue, a keyboard shortcut sheet whose every row is a key the editor really answers, a
splash screen for the desktop build, and a layout setting for the case detection gets wrong.
Two decisions worth reading
A service worker may cache files and nothing else. The first version cached every same-origin GET
and swept up the test harness's own control requests. Under a virtual clock each of those is a pause,
and a cache write hung on every one meant the editor never got a turn to draw — nought tiles of
thirteen. The narrow rule is the correct one anyway: an API answer served from an offline cache is a
wrong answer served confidently. And sw.js must never be cached long, because the worker that would
fetch a newer one is the stale one.
A wide window is not always a desktop. Three layout checks had been failing on CI for days, and
the cause was not a layout fault: the shell asks (any-pointer: fine), which is the only honest
question a page can ask about what is being pointed with, and a headless runner with no mouse answers
no. A 1440 px window was being laid out as a tablet, and the checks were reporting, correctly, that
the picture was 216 px tall — a true statement about a layout nobody meant to check. Every run now
pins the layout it names, and the application carries the choice behind that as a remembered setting.
What this build is
Desktop installers for Windows, Linux and macOS, plus a Docker image carrying the editor, the HTTP API
and the MCP server. The macOS disk image is unsigned unless an Apple certificate was configured, so
Gatekeeper will refuse it until you allow it by hand. Android and iOS assets exist only for releases
built with their signing keys.
FFmpeg is not bundled: the export runs on the browser engine's own encoders, and the server cannot
render.