Bug Description
On CachyOS with KDE Plasma (Wayland), the default Direct paste method never delivers the transcription to Wayland-native apps (I tested with Kate), yet Handy logs Text pasted successfully. Recording, the global shortcut (Ctrl+Space) and transcription all work; only the final text insertion is lost, with no error or warning.
What I see in the log (paste method Direct, typing_tool = auto, none of wtype/kwtype/dotool/ydotool installed):
[handy_app_lib::clipboard][INFO] Using paste method: Direct, delay before: 60ms, delay after: 60ms
[handy_app_lib::clipboard][INFO] Falling back to enigo for direct text input
[enigo::platform::x11][WARN] fast text entry is not possible on X11
[enigo][DEBUG] fast text entry not available. Trying to enter individual letters now (xtest_fake_input calls follow)
[handy_app_lib::actions][DEBUG] Text pasted successfully in 88.964226msThe fallback is enigo's X11/XTEST backend. XTEST events only reach XWayland clients, so a Wayland-native window such as Kate receives nothing. Handy still reports success.
Other things I noticed while digging into this:
kwtypeis the only tool in Handy's list that targets KDE Wayland, but it is not in the official Arch/CachyOS repos (only the AURkwtype-git), so most KDE users fall into the silent enigo-X11 fallback.wtypeneeds a wlroots-style virtual-keyboard protocol that KWin doesn't provide (see #2006).- Korean (non-ASCII) text can't be typed key by key by the keycode-based tools (my expectation for
wtype/ydotool; I did not test them), so for my language only a clipboard-based paste can work. I did not test theClipboard (Ctrl+V)method, but it has to inject a key combo through the same tools, so I expect the same fallback problem.
Expected behavior
Either the transcription is inserted into the focused Wayland window, or Handy tells the user that insertion is not possible in this session (log level WARN/ERROR and ideally a UI hint), instead of reporting success.
Workaround that works
Paste method = External script with a script that puts the text on the clipboard and sends a real Ctrl+V through a /dev/uinput virtual keyboard (the user already has ACL access to /dev/uinput on this distro). Handy passes the text as $1:
#!/usr/bin/env bash
unset PYTHONHOME PYTHONPATH LD_LIBRARY_PATH LD_PRELOAD APPDIR APPIMAGE # see note below
text="$1"; [ -n "$text" ] || exit 0
prev=""; had_prev=0
if wl-paste --list-types 2>/dev/null | grep -q '^text/plain'; then
prev=$(wl-paste -n 2>/dev/null; echo x); prev=${prev%x}; had_prev=1
fi
printf '%s' "$text" | wl-copy || exit 1
sleep 0.05
/usr/bin/python3 - <<'PY' || exit 1
import time
from evdev import UInput, ecodes as e
ui = UInput({e.EV_KEY: [e.KEY_LEFTCTRL, e.KEY_V]}, name="handy-paste-keyboard")
time.sleep(0.5)
for code, val in ((e.KEY_LEFTCTRL, 1), (e.KEY_V, 1), (e.KEY_V, 0), (e.KEY_LEFTCTRL, 0)):
ui.write(e.EV_KEY, code, val); ui.syn(); time.sleep(0.03)
time.sleep(0.15); ui.close()
PY
[ "$had_prev" = 1 ] && { sleep 0.4; printf '%s' "$prev" | wl-copy; }
exit 0With this, Ctrl+Space → speak → Ctrl+Space inserts the Korean transcript into Kate; I verified the document content equals the entry in Handy's history, and the previous clipboard is restored.
Note for anyone copying it: the AppImage leaks its bundled PYTHONHOME/PYTHONPATH/LD_LIBRARY_PATH into the child process, which makes the system python3 die with No module named 'encodings' (script exit code 1 → Failed to paste transcription). Handy could scrub these variables before spawning the external script.
Suggestions
- On Wayland sessions, don't treat the enigo-X11 fallback as a successful paste; warn the user (or return an error) when the focused window can't be reached.
- Consider a built-in Wayland-capable path for KDE/GNOME that doesn't depend on AUR-only tools (e.g. the
xdg-desktop-portalRemoteDesktop/libei input emulation, or/dev/uinput). - Scrub AppImage-specific env vars (
PYTHONHOME,PYTHONPATH,LD_LIBRARY_PATH, ...) for theExternal scriptmethod. - Document the
External scriptworkaround for KDE Wayland.
Related: #2006 (typing tool dropdown on KDE/GNOME Wayland), #1555 (Wayland meta issue), #1729 (AppImage GDK_BACKEND=x11 rendering freeze on the same setup).
System Information
App Version: 0.9.8 (AppImage, run with GDK_BACKEND=wayland via the workaround from #1729; the enigo-X11 fallback above was observed in this configuration)
Operating System: CachyOS x86_64, KDE Plasma 6.7.5 (KWin Wayland session, XDG_SESSION_TYPE=wayland)
CPU: AMD Ryzen 7 5800X
GPU: NVIDIA GeForce RTX 3090
Logs
Relevant excerpt is inline above; transcription text is redacted by Handy's log.
I think this is most likely a duplicate, or at the least known, it's largely a reason why we have multiple paste methods and the external script
Not 100% sure but I am not surprised by this, and it's likely not something easily fixable