Releases: Alsoilia/Traymetry
Release list
Traymetry v0.9.1
Documentation fix. No code changed.
README-FIRST.txt — the first file in the archive — still described Traymetry
as a private test build handed out to friends, and said there was no public
update channel. Both were out of date. It is rewritten for anyone downloading
the release, and it now exists in English (README-FIRST.txt) and Russian
(README-FIRST.ru.txt).
Verifying the download
SHA256SUMS.txt covers all four other assets. The updater checks
Traymetry-update-manifest.txt against Traymetry-update-manifest.sig with
the public key compiled into the executable before it replaces anything.
Traymetry v0.9.0
First stable release.
The code is what 0.9.0-preview.99 shipped — the preview series ran out of
things to fix, so this is a promotion, not a change.
Installing this build moves the installation to the stable channel. A
stable installation ignores prereleases, so preview builds will no longer
offer themselves. Following previews again means installing one by hand.
Verifying the download
SHA256SUMS.txt covers all four other assets. The updater checks
Traymetry-update-manifest.txt against Traymetry-update-manifest.sig with
the public key compiled into the executable before it replaces anything.
Traymetry v0.9.0-preview.99
Bug fixes.
- "Поддержать Traymetry" now opens the payment form directly, instead of the
page it used to open.
Files
| File | Purpose |
|---|---|
Traymetry.exe |
the widget, portable, nothing to install |
Traymetry-0.9.0-preview.99-win-x64.zip |
the same executable with the readme and licences |
Traymetry-update-manifest.txt, .sig |
what an installed copy checks before it updates itself |
SHA256SUMS.txt |
checksums of all four |
Traymetry v0.9.0-preview.98
Fixes a watchdog that kept restarting a mouse hook nothing was wrong with.
0.9.0-preview.97 gave the pinned right click its own hook thread, and added a
watchdog to put that hook back if it ever stopped being called. The watchdog
asked the wrong question. It judged the hook dead from the pointer's position
alone: a cursor somewhere new, with no hook call behind it, meant a hook that
had gone quiet.
But a cursor placed somewhere by SetCursorPos — by a game, a remote desktop,
a magnifier — moves without anybody touching a mouse, and no low-level hook is
called for it. So the widget would find a new position, find no calls, and tear
down and rebuild a perfectly healthy hook. Every two seconds, for as long as it
went on — which, in a game holding the pointer, is the whole session. Exactly
the case pinning exists for.
A restart now needs two things: a cursor that moved and a GetLastInputInfo
tick count that advanced. A warp produces the first and never the second; a hand
on a mouse always produces both.
Measured against one log, before and after: the previous build restarted at
23:44:47, 23:44:49 and 23:44:52 under a script that only warped the pointer.
This one held a single hook through thirty-two seconds of the same warping, and
still took the right press that followed.
Also in this release: the build now refuses to finish if the pinned mouse hook
is not on a thread of its own that answers its message queue. 0.9.0-preview.96
shipped with that click dead and nothing said a word, because every part of the
build reported success — the hook installed, the handle was valid, the code
compiled. --test-mouse-hook asks the one question none of that covered, of the
same class the widget uses rather than of a copy. It was verified by breaking
it: a hook thread that sleeps instead of pumping fails the build.
Files
| File | Purpose |
|---|---|
Traymetry.exe |
the widget, portable, nothing to install |
Traymetry-0.9.0-preview.98-win-x64.zip |
the same executable with the readme and licences |
Traymetry-update-manifest.txt, .sig |
what an installed copy checks before it updates itself |
SHA256SUMS.txt |
checksums of all four |
Traymetry v0.9.0-preview.97
Fixes the pinned right click, which 0.9.0-preview.96 broke.
A pinned widget is taken out of the hit test whole, so the only thing left that can
hear a right or a middle press over it is the low-level mouse hook — and that hook
was installed on the UI thread. The system calls a low-level hook on the thread that
installed it, and only while that thread is asking its queue for a message; a callback
that does not return inside LowLevelHooksTimeout is dropped without a word, with the
handle still valid and the install still reporting success. This program's UI thread
draws a layered window and waits on sensor reads, and it has been measured stalling
for whole seconds.
Measured on 0.9.0-preview.96: the hook was called once, five milliseconds after it was
installed, and never again, while a bare pumping thread elsewhere on the same machine
took 2130 calls in ten seconds.
The hook now runs on a thread that does nothing else and pumps its own queue, and
decides from a snapshot of the widget published forty times a second, so there is
nothing on that thread left to stall. Verified over 43 minutes pinned, with no restart
and every right press taken.
Also in this release: a right click over a pinned widget that is let through now says
what it was judged against, and the first hook call is written down with the thread it
arrived on — "the menu does not open" used to cover two different faults that looked
the same from outside. And a release that is newer than the running build but is not
offered now names the check that turned it down.
Files
| File | Purpose |
|---|---|
Traymetry.exe |
the widget, portable, nothing to install |
Traymetry-0.9.0-preview.97-win-x64.zip |
the same executable with the readme and licences |
Traymetry-update-manifest.txt, .sig |
what an installed copy checks before it updates itself |
SHA256SUMS.txt |
checksums of all four |
Full Changelog: v0.9.0-preview.96...v0.9.0-preview.97