v0.20.6

See CHANGELOG.md for full history.

• Fixed — setting a repeat frequency and its interval no longer races the dialog's own rebuild. Changing the frequency makes Things rebuild that section of the Repeat dialog. The command went looking for the interval field before the rebuild had happened, found the previous layout, and picked its target out of that. It worked — the value it typed survived the rebuild, and the check before committing read the correct number back out — but the field was chosen from a stale picture of the dialog, which is precisely the class of mistake that once wrote an interval into the wrong box. It now waits for the rebuilt section to actually appear before deciding which field to type into.

  Found by counting, not by a failure: a new per-step count of how many controls each step reads came back at 17 where the dialog's own structure demanded about 39, and the missing ones were the controls the rebuild had not created yet.

• Added — THINGS_API_TRACE=1 now records how many controls each step of a GUI-driving command reads. Alongside how long a step took, its trace record now carries how many distinct dialog controls it read the content of. On a real Mac that count is the better predictor of how long a step will take: reading a control's contents makes the app build that part of its interface on demand, while reading positions and sizes is free. Unlike the accessibility round-trip counter added in the same release, this one needs no extra switch and works with the helpers running.

  If you are reporting that a repeat command is slow, a run with THINGS_API_TRACE=1 now says both what your machine cost and what any machine would.

• Fixed — the sidebar probe's five-second estimate was wrong, and said "reachable" when it is not. lab/scripts/field-probe-sidebar.jxa.js — the one-file instrument you can copy to any Mac and run against Things — ended with a predicted time for a sidebar reorder. It worked that prediction out by multiplying the number of questions a sidebar read asks by how long one question takes, and printed "REACHABLE: 3,510 ms". Its own measurements say otherwise: reading the sidebar shallowly and reading it deeply take the same twenty seconds for four times as many elements, while asking every row where it is takes about two milliseconds. The cost is not per question. It is paid once per row whose content is touched, and paid again the next time. The model now prices those two kinds of read separately — they differ by roughly a thousandfold on a real display — and reports the honest number. The full-sweep measurement also now reports milliseconds per row read, beside the per-question figure it always had, with a note saying which of the two means anything.

• Added — the field probe can now measure the three things a screen reader does differently. Three new cells, and a --areas <n> option so the arithmetic is priced at your own sidebar rather than a stand-in.

  • Hit-test: ask the accessibility API what is under a point instead of listing everything, then read one row to confirm it. Reports whether the point resolved to a row and what the whole route cost.
  • Read strategies: the full sweep, the visible-rows-only sweep, and a sparse read (ask every row where it is — which is nearly free — and read the content of only a handful) side by side, in rows-touched and in milliseconds per row touched.
  • Notifications: register for the accessibility notifications a waiting step would want, nudge the scroll bar, and report which ones actually arrived and how quickly. This cell makes one change and undoes it immediately — it moves the sidebar's scroll position and puts it straight back, reporting whether the original value was restored. Nothing else in the probe writes anything, and nothing anywhere in it reads your database.

  The probe's own instructions and safety notes were updated to say all of that plainly, including that two cells now touch the app rather than one.