Wayland: type through wtype and release the overlay's keyboard grab

[SMZ70]

Makes the whip actually land on Wayland compositors. Tested on sway 1.9 / Ubuntu 24.04 with ghostty.

There are already two open Linux PRs (#34, #37), so to be clear about what is different here: this one needs no root daemon, no group membership and no re-login, and it fixes a second bug that neither addresses.

1. xdotool cannot reach Wayland clients

sendMacroLinux currently shells out to xdotool, which drives XTEST. A wlroots compositor does not route XTEST events to Wayland clients, so under sway the macro reaches XWayland windows and nothing else — whipping a Wayland-native terminal silently does nothing at all.

This routes to wtype(1) when WAYLAND_DISPLAY is set, which speaks the virtual-keyboard Wayland protocol. The existing xdotool path is untouched and still used on X11.

wtype needs no daemon and no elevated privileges — it is a plain apt install wtype / pacman -S wtype. That is the main practical difference from #34, which uses ydotool and therefore requires systemctl enable --now ydotool, usermod -aG input, and a logout before it works.

2. The overlay swallows the keystrokes

This one took a while to find, and it bites regardless of which input tool you use.

The overlay is created with setAlwaysOnTop(true, 'screen-saver'), which Electron maps to a layer-shell surface that holds keyboard interactivity. While the whip is on screen, the compositor routes the virtual keyboard to that surface — not to the window it still reports as focused. Every keystroke vanishes into the whip.

The symptom is confusing, because everything looks correct: the right window is focused, and every wtype/ydotool call exits 0. Nothing arrives. Dropping the surface for the ~200 ms the macro takes is what actually releases the keyboard; it is restored immediately afterwards so the whip survives the crack.

I would expect #34 and #37 to hit this too on any wlroots compositor.

3. Focus drifts mid-crack under focus_follows_mouse

sway defaults to focus_follows_mouse=yes, and cracking a whip means flinging the pointer across the screen — so focus lands on whichever window the cursor passed over, and the macro types there.

The focused container is now recorded on tray click, before the overlay appears or the pointer starts moving, and refocused via swaymsg immediately before typing. refocusPreviousApp's Alt+Tab is skipped under Wayland, where it is meaningless: a tiling compositor has no most-recently-used stack to walk, and neither the layer-shell tray nor the focusable: false overlay ever takes keyboard focus in the first place.

This part is sway-specific and degrades gracefully — if swaymsg is not present (Hyprland, GNOME, ...) it falls through to whatever currently has focus, which is the previous behaviour.

Notes

• No new dependencies; wtype is invoked through execFile with an argv array, and the phrase is passed after -- so a text starting with - is never parsed as an option.
• X11 and the Windows/macOS paths are unchanged.