0:30:browser:github
That's a folder name from my video editor. It means start at zero seconds, run for thirty seconds, use a browser element and call it github.
My timeline is a directory listing.
I'm making this editor for my YouTube channel. The scenes and clips are for my own videos, so I have somewhere to use the arrangement while I'm still working it out.
I've been working on an editor using the idea I wrote about in Web components are worth betting on. Give each piece presentation and behaviour, then put the pieces together. A video seems like an interesting place to try that.
A browser window, terminal, banner or camera clip can be a little collection of files. I can copy that collection into another video. The folder carries the element and its name says when to show it, so I can poke at the arrangement with ordinary file tools, which appeals to me.
Pieces I can carry between videos
A browser window shouldn't need to know which video it's in. The video supplies position, size and timing, while the browser piece handles the content inside that window.
The component implementation is the reusable code, while an instance is one use of it with this video's configuration and assets. Two browser windows can use the same implementation and still have different content and start times. That's the distinction I need here.
I'm experimenting with native custom elements for these building blocks. The browser can create a registered element, and that element can manage its own view. That gives me a place to put behaviour without adding every detail to the player.
Writing the pieces is less settled. I'm trying separate HTML, JavaScript and CSS files, with HTML statically bundled into the JavaScript. Individual tools have separate bundles. Some experiments are hardcoded JavaScript things instead. It's a proof of concept.
It feels hacky.
The separate files let me write HTML as HTML, which I like. Then I have to get it into the component's JavaScript, attach the styles to the right piece, decide where the next bit belongs. I can spend a long time arranging the files before I've changed anything visible in the video.
I haven't picked one pleasant way to do all of that yet. For now the directory gives the content and configuration a home together.
At least I can find the piece I'm fiddling with.
From folders to a timeline
The convention is start:length:type:name. Here is a small illustrative pair:
0:30:browser:github/
30:20:browser:docs/
github occupies the interval from zero up to thirty seconds, excluding the end time, while docs starts at thirty and ends at fifty. At exactly thirty seconds docs is active and github is finished. Nobody has to share that boundary instant.
The browser element can keep its layout in a configuration file. Timing belongs to the name in this convention, while position and dimensions live inside the folder. That separates “when does this appear?” from “what does it look like?”.
Moving the folder shouldn't mean rewriting its animation. Start a clip at thirty seconds and it sees the player's thirty-five as five seconds into the clip. That local clock lets the animation start at zero wherever I drop it into the video. The element gets its little world.
I can now move docs earlier:
20:20:browser:docs/
Now they overlap for ten seconds. Do I want both visible? Does one cover the other? Those are composition decisions the player needs rules for. I've managed to describe the overlap by renaming something, but I haven't managed to make the editing decision disappear.
The worker's job is to notice changed files, build the affected video's description and publish that description and its assets, which the browser player can then read. Files and storage belong to the worker. The player deals with the video I'm watching. I'm starting with an object-storage client from an SDK example, which gives me something concrete to connect before bringing the watching and per-video builds together. Those are the next jobs for the worker.
The build translates from folders to a manifest, reading the directories, sorting numerically by the first field and splitting the names into a structured description. The browser can read that without learning my filename convention.
Sorting by the whole string would be a trap, because a name beginning with 100 can come before one beginning with 20 in lexical order. The first field means a number, so the build needs a numeric comparison. A timeline that sorts like a dictionary is an unusual editing experience.
I'd check the names while making that file too. If I've left a duration out, I'd like to hear about it before watching the video to find the missing clip. And the error should name the folder. A duplicate identity or an unsupported element type needs an equally deliberate response.
The browser side remains JavaScript and TypeScript. The Go builder has types for the manifest too, and both sides need to agree about the fields. A duration called one thing by the builder and another by the player would undo a fair amount of this tidiness. I'd like the tooling to maintain that agreement.
For the player, the useful result is ordinary data about the elements and their timing. Only the builder has to hear about it if I change how the directories are named.
One program to build it
Go suits that arrangement. I can keep the watcher, builders and storage client in one program and build an executable for the container. Building with CGO_ENABLED=0 leaves this program without a dependency on C libraries, and although there are still settings and certificates to provide, the thing I'm deploying is one executable.
What a directory buys
I can inspect the folders with ordinary file tools, compare their start times in version control, copy an element with its assets and configuration, and none of those jobs needs a special project-file reader.
I'm asking a filename to hold a lot here. If I want another field, I have to change the naming convention or put it in a file inside the folder. I also have to decide what happens if a name contains the delimiter. And then there are the different naming rules on different filesystems. I can rename a clip quickly. Keeping that convenience across these cases takes some care.
I could keep adding fields to the name, and eventually the directory listing would be the least readable part of my supposedly readable editor. The four fields still do useful work. More elaborate configuration can stay inside the folder, with the manifest carrying the result to the player.
For now, I can change thirty to twenty, rebuild, and see a clip arrive ten seconds earlier. That is a satisfying amount of editing to get from a rename.
I'm enjoying this peculiar little editor.