fix(typer): use ClipboardManager instead of pyperclip for clipboard paste

[nicktoper]

Problem

SimulatedTyper._paste() calls pyperclip.copy() directly, bypassing VOXD's own ClipboardManager.

When PyGObject is installed, pyperclip selects its gi/GTK backend:

>>> pyperclip.determine_clipboard()[0].__name__
'copy_gi'

That backend needs a running GTK main loop to own the clipboard selection. VOXD has no such loop, so the copy silently evaporates — the clipboard ends up owned by nobody, and the Ctrl+Shift+V sent immediately afterwards pastes nothing.

Reproduced on Pop!_OS 24.04 / COSMIC / Wayland, VOXD 1.7.0, with typing_delay: 0 (which routes through _paste()):

$ wl-paste
Nothing is copied

The transcript itself was fine — it was written correctly to output/last_recording.txt. Only the clipboard hop failed.

Why it matters beyond Wayland

The clipboard path is the natural workaround for #19 (keyboard layout issue), where ydotool's keycode injection produces scrambled text on non-QWERTY layouts — AZERTY, QWERTZ, Colemak, pt-br and Swedish are all reported there. One commenter on that issue notes the clipboard route "doesn't work" for them either, which this bug would explain: the workaround silently fails wherever pyperclip picks the gi backend.

I hit this myself on AZERTY: keycode typing scrambled the text, so I switched to paste mode and got nothing at all.

Fix

Route _paste() through ClipboardManager, which already resolves the correct backend (wl-copy on Wayland, xclip/xsel on X11) and owns the selection properly. The class already existed and was already used elsewhere in the codebase — this just stops _paste() from going around it.

The now-unused import pyperclip is dropped from typer.py. clipboard.py still imports it for its own pyperclip fallback backend, so nothing else changes.

Verification

Before, after a transcription:

$ wl-paste
Nothing is copied

After:

$ wl-paste
Ceci est un test de français — accents: éàçùô

Accented characters survive the round-trip, and paste-into-window works in both terminal and GUI apps. Also confirmed ClipboardManager() resolves to wl-copy on this system, and that typer.py imports cleanly with no circular-import issue (clipboard.py only pulls in voxd.utils.libw).

I could only test on Wayland/COSMIC — an X11 check would be worth having, though that path goes through xclip/xsel, which ClipboardManager has handled all along.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 583e9ccbf7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Restore fallback when ClipboardManager cannot copy

When paste mode is used in an environment where the selected clipboard backend cannot actually copy (for example no wl-copy/xclip/xsel so ClipboardManager falls back to pyperclip and pyperclip raises, or xclip/wl-copy exits non-zero), ClipboardManager.copy() logs and returns instead of raising, so this try still proceeds to send the paste shortcut and can paste stale clipboard contents or nothing. The previous direct pyperclip.copy() path would enter the existing _type_char_by_char fallback on copy failure; this call needs equivalent failure signaling before triggering Ctrl+V/Ctrl+Shift+V.

Useful? React with 👍 / 👎.