ImageForge 1.3.1: one window, one queue

One user report, two operating systems, two root causes with nothing in common. On the Mac, dropping four images on the Dock icon opened four windows and put the batch in one of them. On Windows, “Open with ImageForge” opened the app with an empty list, however many files you gave it. 1.3.1 fixes both — and how each one broke is worth telling.

The Mac opened one window per image

Drop four images on the Dock icon and four windows appeared, each with its own empty list, all of them competing to receive the batch. The cause was not our code: the main window was declared as a SwiftUI WindowGroup, and a WindowGroup opens one window per document when macOS delivers the open-documents Apple Event. The system trace shows it without ambiguity — a single event carrying four files, and then four windows created, all before our code had seen a single URL. The batch went into one of them and there was no controlling which one came to the front, so the app frequently looked as if it had opened with nothing to compress, and trying again just added more empty windows.

The fix was not defensive code around the problem, but declaring what the app always was: one window with one queue. The scene is now a SwiftUI Window, a single instance that neither the Apple Event nor anything else can duplicate. “New Window” has left the File menu for the same reason — if you close the window, bring it back with Window ▸ ImageForge Window (⌘0), by clicking the Dock icon, or from the menu bar item.

Windows never read the files at all

The Windows app declared its file type association from the very first release, so Windows offered “Open with ImageForge” and accepted files dropped on its icon. It just never read them: WinUI funnels every activation through a single startup method, and ours created the window and threw the arguments away. The association was decorative — the app opened with an empty list whether you handed it one image or twenty.

Fixing it turned up something we had assumed wrong. For a packaged desktop app, the Windows shell does not hand over a selection as one activation: it starts one process per file, each with a single path on its command line. Four images meant four processes. So the fix has two halves: read the paths from the command line, and elect a primary process that the others hand their files to before exiting. The result is what you would expect from the start — one window, one queue, however many files you select.

Two bugs, one lesson

Both bugs lived in the boundary between the app and the operating system — the part you cannot unit-test, because the only way to know what the shell really does is to watch it do it. Both were found by reading system traces rather than by reasoning about the code, and in both cases the code was doing exactly what we had told it to. 1.3.1 is live on the Mac App Store and the Microsoft Store; as always, everything happens on your machine and nothing is ever uploaded.