wflow 1.0: keyboard-trigger automation for Wayland (Plasma 6, GNOME 46+, Hyprland, Sway)

Posted by DaCush@reddit | linux | View on Reddit | 4 comments

I've been building wflow for the last couple of months. It's a desktop automation tool: bind a keyboard chord like ctrl+alt+t, fire a workflow. Workflows are plain-text KDL files you can also build in a Qt GUI. The 1.0 release is what I'm posting today.

What it actually does, in one sentence: AutoHotkey-style chord triggers, but on Wayland, where AHK doesn't run and where the existing options stop at "open one app on a global hotkey".

The trigger daemon probes for a backend at startup. KDE Plasma 6 and GNOME 46+ get the GlobalShortcuts portal (the consent-dialog one, no sudo, no special groups). Hyprland gets IPC over $XDG_RUNTIME_DIR/hypr/.... Sway gets the i3 IPC bindsym ... exec route. The daemon hot-reloads on workflow file changes via inotify. Compositor IPC mode is fully live; portal mode needs a daemon restart for new bindings (that's a spec limitation, not laziness).

A workflow looks like this:

workflow "Focus mode" {
    trigger {
        chord "ctrl+alt+f"
    }

    shell "swaync-client -d"
    shell "pactl set-sink-mute @DEFAULT_SINK@ 1"
    focus "Editor"
    notify "head down" body="focus mode on"
}

That's the whole file. Ten lines. Diffable, shareable, version-control friendly. The GUI is a view onto the file; edit either side, the other catches up.

Alongside the desktop release I'm also launching wflows.io, a catalog where people can publish and share workflows. One-click "Open in wflow" from any page, the desktop catches the wflow://import?source=... URL, shows a confirm dialog with title / author / description / step count, drops it in your library if you say yes. Drive-by URLs can't silently install anything.

Install: - Arch: paru -S wflow-bin (prebuilt) or paru -S wflow (source build) - Tarball + INSTALL.txt: github.com/cushycush/wflow/releases/latest - Flatpak: manifest is in the repo, Flathub submission is in flight - Catalog + docs: wflows.io

What I want feedback on, honestly: - Compositor coverage. I've tested Plasma 6, GNOME 46+, Hyprland, Sway. River, Niri, Cosmic — if you're on one of those and it breaks, the issues page is open. - The KDL format. It's a plain-text file format I built the parser for myself. It's fine. It's also probably going to surface edge cases nobody else has hit yet. Roast it. - The trust prompt. First time you run a workflow you didn't write, wflow shows a categorized step summary and asks you to confirm. Annoying? Necessary? Both? Tell me.

Source for the desktop is at github.com/cushycush/wflow (Rust + Qt Quick). Source for the catalog is at github.com/cushycush/wflows (Next.js + Postgres + Drizzle). Both dual MIT/Apache.

There's a Discord linked from wflows.io if you want to talk through anything in real time, otherwise the GitHub issues page is the right spot for bugs.

[-]

tonibaldwin1@reddit

Nice! I especially like the sharing feature because I haven't really developed workflow for myself beside opening the four apps I use to work every morning.

aloobhujiyaay@reddit

The portal limitation on GNOME/KDE sounds annoying but understandable

DaCush@reddit (OP)

Yeah, it's a real tradeoff. The portal makes you accept each chord through a system dialog the first time, which feels heavy if you're used to AHK where you just bind whatever you want and go. But the alternative is what the X11 era looked like: any process can grab any keypress globally with no user awareness, which is exactly the threat model Wayland was designed to fix. So I think the portal is the right answer even though it stings the first time you set up 20 chords.

A few things that take the edge off in practice:

- The dialog is one-time per chord, not per-trigger. Once you've accepted ctrl+alt+t, it just works for the lifetime of the binding.
- Plasma 6 and GNOME 46+ both let you review and revoke granted shortcuts in system settings, which is the upside of the portal model. AHK on Windows had no equivalent.
- For people on Hyprland or Sway, the IPC fallback skips the portal entirely. Same engine, no consent dialog, because the compositor handles the bind directly. That's a real "if you want zero friction, use a wlroots compositor" answer, which I know is its own thing.

The honest gap is bulk import. If someone publishes a workflow pack with 15 chords on wflows.io and you install all of them, you get 15 dialogs. I'm thinking about whether the portal supports batched grants, but the current state is one-at-a-time.

ucsilahsor@reddit

does this work on Niri?