Handy Tool 1.3.0 - the RDP delivery fix

If you dictate into RDP or Citrix, install this one. It undoes a mistake in 1.2.0 and fixes an older defect that was hiding behind it.

What 1.2.0 got wrong

1.2.0 started typing into remote desktop windows instead of pasting, to keep your transcript off the remote machine's clipboard. The privacy goal was real. The delivery was not: text arrived with characters missing, characters jumbled, and line breaks nobody dictated.

That behaviour is removed. There is nothing to switch off — the switch is gone.

Why it failed, precisely, because it is not what the 1.2.0 notes assumed. Typing sent each batch of 40 characters as a single instantaneous burst of input events into the remote session's virtual channel. Pausing between bursts does not make any one burst gentler. And when the take used Transcribe & Submit, the Enter key fired about 50 ms after the last batch — while the text was still crossing the wire. The message got submitted in pieces. That is where the phantom line breaks came from: not from your dictation, but from Enter arriving too early, repeatedly.

Keystroke delivery still exists, but only as a deliberate choice: Advanced › Transcription › Transcribe › Paste method = Direct. It carries the caveats it always had, which this project's own docs have stated all along — it can drop characters in RDP, Citrix and VM consoles.

The older bug underneath it

This one affected clipboard pastes too, and had been there for months.

The Local / Remote desktop delays only ever applied when Handy had jumped to the target window. Dictating into a remote window that already had focus — the ordinary way most people work — took neither branch and waited not at all. You could set a 500 ms remote submit delay and have it never once apply.

Remote targets now get their remote timing whether Handy activated the window or not.

An already-focused local target still submits instantly. That is deliberate, and there is a test named after it, because the obvious version of this fix would have added half a second to every ordinary dictation.

The setting was called Submit delay after jump, which was true before and is not now. It is now Submit delay before Enter. Your configured value is preserved.

Also fixed

• A failed submit no longer claims the text wasn't delivered. It used to, so you would press Paste Last and end up with the transcript inserted twice. It now says plainly that the text arrived and only the submit key was withheld.
• Direct no longer rushes line breaks. Return and Tab were injected with no pause and didn't count toward pacing, so a blank line fired two Enter presses back-to-back at machine speed.
• The documented delay defaults were wrong in three places. The code has always meant 300 ms local / 600 ms remote; the settings UI fell back to 250 ms / 1 s and all 17 languages quoted those wrong numbers. If you never changed the delays, your behaviour didn't change — only the numbers you were shown.

New

Clipboard restore delay for remote desktops (Advanced › Transcription › Transcribe). An optional separate restore delay for remote targets, so a local paste stays fast while a remote one gets the time RDP needs to fetch the clipboard before your original is put back. Unset by default — it changes nothing until you pick a value. 1 s is a sensible start.

The honest trade

Remote targets use a clipboard paste method again. That means your transcript does reach the remote machine's clipboard and its clipboard history, and nothing on this side can retract it. That is the deliberate choice in this release: your dictation arriving intact matters more. Direct remains the only delivery path that touches no clipboard, with its reliability costs attached.

Verification

269 unit tests pass. The change went through independent adversarial review, which corrected the plan twice before any code was written: flipping the feature's default would have fixed nobody, because a store written since 1.2.0 holds the value explicitly — removal was actually the cheaper option; and the obvious place to add the missing remote wait would have added a full second per dictation while improving nothing, because that particular wait runs before the clipboard is even written.

The diagnosis came from the reporter's own debug log, which is also why 1.3.0 adds jumped, remote and the resolved wait to the timing lines — so the next remote session proves the fix rather than assuming it.

Install

Windows x64. The installer is not code-signed, so SmartScreen will warn — More info → Run anyway. If Smart App Control blocks it outright, use the portable ZIP, which needs no installer.

macOS builds are produced separately and remain experimental and unnotarized; Linux is still planned.