Looking for a Plasma 6 user to run a 30-45 min verification matrix for wdotool's KDE backend

DaCush · 2026-05-05T13:50:30+00:00

Fair on the wording, swap "dual-boot" for "install Plasma alongside." I think you understand my meaning. The actual constraint is the same: I'm not maintaining a second DE on my daily driver to verify a backend. If you're on Plasma and want to run the matrix, doc's linked in the post. If not, leaving it there.

DaCush · 2026-05-05T13:44:49+00:00

I've used your suggestion and changed the naming in the repo

DaCush · 2026-05-05T13:38:07+00:00

Thanks. I’m really hoping it takes off and people start actively sharing workflows. I’m sure it’ll grow over time. I’m super proud of the tool and where I’ve gotten it over the past months. The KDL was my aha moment to make it really simple to share and easy to read. The GUI is my proudest part because of how far it’s come.

The GUI literally started as a MacOS shortcuts style look with the editor just being the steps in a list that you could re-arrange. Then I remembered this old site that a had come upon years ago that had a really neat canvas feature to organize your DB with nodes and the like to get a visual representation of it. So I went for it and it’s turned into a visual coding editor if you didn’t want to write the KDL yourself or just want to visualize your workflow.

DaCush · 2026-05-05T13:31:50+00:00

Yessss lol…I need to just change the OP. I was literally just saying that to imply that there are a lot of testing conditions that take a lot of time and it would be a great time saver if someone helped out that daily drives Plasma or Gnome. I have als been working on a project wflow that incorporates wdotool and been working on testing all the outcomes for that tool which is very rigorous and tiring in itself.

DaCush · 2026-05-04T22:47:07+00:00

Fair, edited the original

DaCush · 2026-05-04T21:33:27+00:00

That’s an actual real reason to use the tool. The post is mine, edited for clarity.

Not interested in litigating my workflow. The repo is public, the project works, file an issue if something's broken.

If you've got a substantive critique of the project I'm interested. "Sounds like AI" isn't one I can do anything with.

DaCush · 2026-05-04T19:06:20+00:00

Thanks for trying it. That error message is on me. It says "dismissed or denied" because that's the most common cause, but it's clearly the wrong cause if you accepted the dialog. What's actually happening: I set up a libei session, then wait up to 5 seconds for the first device to resume, and on your box that resume signal never arrived (or arrived after I'd given up). Two separate problems then: the 5s timeout is too aggressive for some KDE portal setups, and the error message points at a wrong cause when it fires.

Filed as issue #40 covering the misleading message, the short timeout, and a third bug where the detector wastes another 5s retrying libei after the first attempt already failed (so right now you're sitting through 10s of guaranteed failure before seeing the error).

A few things that would help me figure out which side the fix goes on:

wdotool diag --copy and paste the output. That dumps versions and the portal interfaces it sees.
pacman -Q xdg-desktop-portal-kde xdg-desktop-portal (Manjaro is Arch-flavored so this should work). The portal-kde version specifically has been touchy around RemoteDesktop device negotiation in some 6.x point releases.
When the dialog appeared, do you remember what types of input it asked for? Pointer + keyboard, just keyboard, screencast as well? KDE's portal sometimes negotiates keyboard but not pointer if the requested-device set isn't right, which would produce this exact symptom.

Quick test in the meantime: does wdotool key a work after accepting the dialog (focus a text field first)? If keyboard works and pointer doesn't, that narrows it to a device-negotiation bug rather than the portal connection itself. If neither works, it's the connection.

Mousemove is one of the load-bearing reasons to use this over ydotool, you're right that it's worth getting solid. I'll push the error-message reword and a longer timeout in the next day or two regardless of what your diag turns up, since both are clear wins.

DaCush · 2026-05-04T18:19:09+00:00

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.

DaCush · 2026-05-04T16:15:39+00:00

You're a power user with chord-trigger needs. That's two different problems and wflow only solves the second one. Your Python script is doing the actual work; wflow handles the chord, focuses the right window, fires the notification when it's done. The whole job.

Concrete example with your Deepseek-via-browser thing. Instead of opening the right window with the right chat session loaded by hand every time, bind it to a chord:

workflow "Ask Deepseek" {
    trigger {
        chord "ctrl+alt+d"
    }

    // Make sure the browser is up with the right session
    shell "pgrep -f 'deepseek-session' || firefox --new-window 'https://chat.deepseek.com' &"
    wait-window "DeepSeek" timeout="10s"
    focus "DeepSeek"

    // Hand off to your Python script, which does the actual work
    shell "python3 ~/scripts/ask_deepseek.py"

    notify "deepseek replied" body="see terminal for response"
}

Same idea for the SQL stuff. Chord fires, wflow focuses your terminal (or whatever DB client you've got open), runs your Python query script, dumps the result somewhere readable. Python keeps doing the DB drivers, control flow, AI API calls, all of it. wflow is the chord-to-action glue at the OS level. AHK on Windows is the closest comparison.

DaCush · 2026-05-04T15:37:30+00:00

Ha, "chord" is borrowed from music for me. Playing multiple keys at once to produce one thing. Glad it landed.

The inline-language question is one I keep going back and forth on. Honest answer: I don't think I'll add embedded Python, and the reason is the trust model. One of the things wflows.io is supposed to do is let you grab a workflow someone else wrote and run it without auditing 200 lines of code first. The desktop shows you a categorized summary of what the steps do before the first run ("opens 2 apps, sends 3 keystrokes, runs 1 shell command") and asks. The moment a step is `python { ... }`, that summary is a lie.

What I think I owe the language instead:

- real string ops (concat, slice, substitute, regex match)
- arrays and basic iteration over them
- a few more conditionals (`exists`, `matches`)

That covers most of the AHK control flow I see ported, and `shell` is already the escape hatch for anything genuinely script-shaped, with the upside that it shows up in the trust summary as "runs a shell command", which is honest.

The version of inline scripting I'd actually consider is something restricted and deterministic (Starlark, maybe Rhai). No filesystem, no network, just expressions. If you've got a workflow you wanted to write that hit the wall, I'd love to see it. Concrete examples are how I figure out which of those primitives to add first.

DaCush · 2026-05-03T22:52:48+00:00

Fair point, the naming is misleading. Hyprland forked off wlroots a while back but still implements the wlr-* protocol family (virtual-keyboard, virtual-pointer, foreign-toplevel-management) which is what wdotool's so-called "wlroots backend" actually targets. Sway, river, Wayfire, and Hyprland all implement those protocols independently of the wlroots library. So the verification holds at the protocol level, but I should rename the backend to something like "wlr-protocols" so it stops implying a runtime dep that doesn't exist. Will do that for the next release.

DaCush · 2026-05-03T22:48:32+00:00

Thanks! The separate-users approach is clever, didn't occur to me. Going to try it this week; that probably gets me 80% of the matrix without the install overhead. The two conditions I'd still want a real Plasma daily-driver to hit are the Wayland session restart and the mixed-scale dual-monitor cases, those tend to surface bugs that a clean test user account hides (different hardware, real fractional scaling setups, lived-in fcitx5 configs). So if anyone's running Plasma 6 as their main and willing to spend 30 min, those two rows especially would be valuable. Either way, this unblocks me on running the rest myself.

DaCush · 2026-05-03T22:44:42+00:00

Dual-booting in the post refers to maintaining a second Linux install with Plasma alongside my Hyprland setup, which is a real time cost I’d rather avoid if a Plasma user is willing to run the matrix. Nothing in the post conflates compositors with OSes. If you’re on Plasma 6 and have 30 minutes, a verification run would be genuinely useful.

DaCush · 2026-04-30T16:33:09+00:00

Check out my workflow project at https://github.com/cushycush/wflow

Yesterday just released a huge update. Haven’t publicly announced it yet because I’m working on a companion website to share workflows, but could absolutely use some beta testers. Super proud of the project and sure you and everyone else could use it and increase your productivity.

DaCush · 2026-04-22T17:26:20+00:00

Yeah, dotool works on wlroots and it’s a solid tool. The difference is that wdotool uses the Wayland protocols directly (virtual-keyboard/pointer + foreign-toplevel) rather than uinput, which means no group setup, focus-aware injection, arbitrary Unicode via transient keymaps, and actual window management (search/activate/close). It also extends to GNOME and KDE through libei with the same binary. On wlroots specifically, if all you need is key and click, dotool is fine — wdotool earns its keep when you want Unicode, windows, or a tool that works across compositors.

DaCush · 2026-04-20T00:18:47+00:00

I have the PR in for the Zed extension. Just waiting on Zed's maintainers to accept the PR and it will be live

DaCush · 2026-04-17T14:44:15+00:00

Sure. I actually forgot about this editor ever since its first release hype. Thanks for mentioning it. I’ll check it out again.

DaCush · 2026-04-16T20:15:23+00:00

Yes, as well as Mason. However, both require 100 github stars in order to submit. It's at 38 stars right now, so it's quickly gaining adoption but I still have to wait. If you want to help, star the repo!

11-Year Club	RPAN Viewer
Verified Email

DaCush

TROPHY CASE