u/DaCush

Repo + install: https://github.com/cushycush/wflow (stars help with discovery on the awesome-lists if it's your kind of thing)

Built a desktop automation tool that binds keyboard chords to multi-step workflows on Wayland. The interesting bit for this sub is the backend probe: at startup the daemon looks for org.freedesktop.portal.GlobalShortcuts, falls back to Hyprland IPC on $XDG_RUNTIME_DIR/hypr/$HIS/.socket.sock, falls back to Sway IPC on $SWAYSOCK via the i3 RUN_COMMAND protocol. Whatever's there wins.

Tested against:

• KDE Plasma 6 (portal)
• GNOME 46+ (portal)
• Hyprland (IPC)
• Sway (IPC)

Workflow file is plain-text KDL on disk, hot-reloads via inotify on the IPC backends. Portal mode needs a daemon restart for new bindings, which is a portal-spec limitation rather than a wflow one.

If you're on River, Niri, Cosmic, or anything else with its own IPC shape, I'd love a hand. Issues open at github.com/cushycush/wflow.

Catalog and docs: wflows.io.

Repo + install: https://github.com/cushycush/wflow (stars help with discovery on the awesome-lists if it's your kind of thing)

Long-time AHK lurker, mostly. The shape of "press a chord, fire a script" is the move I miss most when I'm on my Linux machine. xdotool

• a compositor bind sort of works, but xdotool doesn't run on Wayland, the workflow file is split across three different config files, and text expansion is a different tool entirely.

So I built wflow. It's not AHK. It's not as old, the language isn't as deep, and the Windows-side IME / window-class feature set isn't the same. But on Linux specifically, on Wayland specifically, it's the piece I wanted:

• Bind ctrl+alt+t (or any chord your compositor will let go of) to a multi-step workflow
• Steps include shell, key, type, focus, wait, repeat, and conditionals. Same shape as Send, Run, WinActivate, if/else.
• All in one plain-text file per workflow. Diff it, version it, share it.
• A GUI editor for the people who don't want to hand-write the file, including a step-by-step debugger that pauses between actions.
• A daemon that probes the right backend at startup (GlobalShortcuts portal on Plasma 6 / GNOME 46+, IPC on Hyprland and Sway).

AHK example, your daily standup:

::stand::
Run, slack
WinActivate, Slack
Send, ^k
SendInput, #standup-platform
Send, {Enter}
return

Same workflow as a .kdl file:

workflow "Morning standup" {
    trigger {
        hotstring ";stand"
    }

    shell "hyprctl dispatch exec 'slack'"
    wait-window "Slack" timeout="20s"
    focus "Slack"
    key "ctrl+k" clear-modifiers=#true
    type "#standup-platform"
    key "Return"
}

I'd love AHK people to roast it. I'm aware of how thin the language is compared to AHK v2 right now (no expression-level scripting, no real string functions, no array primitives). The deliberate trade is that the file format is also the file you ship to other people, so I kept the surface small. There's an include mechanism for shared fragments, and shell plus repeat plus conditionals get you to the same place AHK control flow does for most chord shortcuts I see in the sub. But yes, the gap is real.

If you want to try it: wflows.io for the catalog, github.com/cushycush/wflow for the source. I'd rather hear "this fails on the workflow I actually wanted to port" than fluffy applause, so feel free to break it.

wdotool is an xdotool replacement for Wayland. It uses libei via the RemoteDesktop portal for input and KWin scripting (same machinery as kdotool) for window ops on KDE. The code has shipped since v0.1.x and unit tests pass, but I've never run the matrix on a real Plasma session because I'm on Hyprland and won't dual-boot just to verify it. So right now the strongest claim I can make about the KDE backend is "I think it works," which is not a great claim to ship under.

The verification doc is here: docs/verification/kde-plasma-6.md.

Twelve operations (key, type, mousemove, click, scroll, search, windowactivate, etc.) across six conditions:

• Default
• Fractional 125%
• Fractional 175%
• Mixed-scale dual-monitor
• Wayland session restart
• fcitx5 active

Plus two special tests: portal token revoke + recovery, and a 5-step wflow workflow that exercises the one-consent-many-ops property end-to-end (wflow migrated to wdotool-core as a library in v0.6.0, so this test is now first-class instead of the "TODO once wflow migrates" placeholder it used to be). Each cell takes a ✅ / ❌ / N/A. ~30-45 min if everything passes.

If anything fails I'll fix it or file it as its own issue, no expectation that you debug. Just need real-hardware ground truth from someone whose daily driver is Plasma. The PR closes issue #1.

For comparison with the alternatives: xdotool is X11-only, ydotool writes to /dev/uinput which means root and no compositor focus awareness. wdotool stays inside the portal permission model, which is why KDE specifically matters (the consent dialog flow is half the surface I need verified).