Repository navigation
A patch release over v2.0.1. No new capability, no change to the file format or the
exports — a project written by v2.0.1 opens here and the other way round. The web editor
is unchanged and still lives at
acwright.github.io/TMS9918-EDITOR.
Downloads
| Platform | File | First run |
|---|---|---|
| macOS (Apple silicon) | tms9918-editor-2.0.2-mac-arm64.dmg |
Signed and notarized — opens with no Gatekeeper prompt |
| Windows (x64) | tms9918-editor-2.0.2-win-x64.exe |
Unsigned installer, so SmartScreen warns — More info → Run anyway |
| Linux (x64) | tms9918-editor-2.0.2-linux-x86_64.AppImage |
chmod +x, then run |
| Linux (x64) | tms9918-editor-2.0.2-linux-amd64.deb |
sudo apt install ./tms9918-editor-2.0.2-linux-amd64.deb |
Double-clicking a project opens that project
On macOS, double-clicking a .tms9918 file while the app was closed opened whichever
document the app had open when it last quit. The file you clicked was reached only if it
happened to be that same document — otherwise it was simply dropped, with no error and
nothing on screen to say so. Double-clicking against the running app always worked, and
Windows and Linux were never affected.
Two halves of the launch were each right on their own. A double-click on macOS is
delivered as an open-file event that fires before the app is ready — measured at the
time, and the reason the handler is installed as early as it is — so the clicked path
waits in a queue until the editor is up and can ask for it. Meanwhile the app, finding no
document named on its command line (macOS never puts one there), fell back to reopening
whatever was open at the last quit. That fallback went through the same queue, and
overwrote the path the double-click had already put in it.
The launch now asks whether a document is already waiting before it reaches for the
remembered one, and the whole decision lives in one function rather than split across two
files. A launch that asked for nothing at all still returns you to the document you were
last in.