# Utterform 0.6.1 — Live dictation restarts cleanly on Omarchy

A stability release for **GPT Live Transcribe on Omarchy/Hyprland**. Starting a second
Live dictation in the same text field could stop at once with *"Live typing paused
because the target or desktop focus changed"*, sometimes together with a workspace
jump the user never asked for. GPT Transcribe, Local Whisper and Windows Live are
unchanged in behaviour.

## What was wrong

- **Any desktop event counted as losing the target.** The Hyprland focus observer
  treated every `workspace`, `focusedmon`, `activespecial`, `openlayer`, `submap`,
  `configreloaded` and monitor event as a permanent loss of the text field, even when
  the active window address never changed. One on-screen-display layer or one
  workspace event was enough to end insertion for the rest of that recording, and a
  session that had just started could be ended while it was still connecting, because
  the target was re-checked every 20 ms during the OpenAI handshake.
- **Utterform's own keystrokes could trigger Omarchy shortcuts.** Hyprland resolves its
  key bindings for a virtual keyboard through the compositor's *own* layout by keycode,
  with the modifiers of every keyboard merged in, not through the keymap Utterform
  uploads. Utterform placed "ä" on the keycode Omarchy binds to *XF86AudioPlay*
  (play/pause plus an OSD layer, which then ended the session as a "focus change"),
  "." on the Tab keycode and "!"…")" on the keycodes Omarchy binds with Super to
  workspaces 1–9. While the Super key of the stop shortcut was still held, the last
  words of a dictation could therefore switch the workspace or resize the window.
- **Chromium on Wayland dropped or misread some keys.** Chromium ignores keys whose
  evdev code has no DOM code ("s", "ä", "à", "ê" and others never arrived) and derives
  editing behaviour from the key's US-layout meaning ("-" sat on Backspace and deleted
  the previous character).

## What changed

- **Only a confirmed window change or a closed target window stops Live.** Workspace,
  monitor, layer, submap and config-reload events alone never do. Keyboard focus
  leaving every window (a launcher, for example) blocks only text that would have been
  typed while it lasted.
- **Focus is confirmed per text chunk, not every 20 ms and not per character.** One
  synchronous Hyprland query before each chunk, queued events after it; idle time only
  reads queued events.
- **Technical faults are reported as such.** A Hyprland query is retried before typing
  stops, and a dead socket or timeout is worded as a technical fault, never as the user
  having switched windows.
- **Keys are placed away from shortcuts and editing keys.** Characters go on keypad,
  F13–F19/F24, international and legacy keycodes first; Escape, Tab, Backspace, Return,
  modifiers, F1–F12, navigation, media, brightness, print and power keycodes are never
  used, and every keycode has a DOM code so Chromium accepts it. After a stop is
  requested, typing waits 700 ms for the shortcut's modifier to be released.
- **Each Live session is isolated and numbered.** A new session refuses to start until
  the previous worker has released its virtual keyboard and event socket; late events
  of an old session cannot affect a new one. The log (`utterform.log`, path shown in
  Settings) records per session the target window address and workspace id, the
  classified focus events, worker start/stop and keymap uploads. No transcript text,
  titles or keys are logged.

## Please verify on a real Omarchy desktop

At least ten rounds of *Super+D → speak → Super+D → start again in the same field*, in
a native Wayland editor, in Chromium and in an XWayland application: no focus error, no
workspace change caused by Utterform, no old or duplicated text, insertion at the
current cursor. Switching to another window during Live must still stop insertion
without replay; "ä", "s" and "-" must arrive in Chromium. The release pipeline built
and packaged all three platforms; microphone-to-field behaviour is not automated.