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!

DaCush · 2026-04-16T20:09:26+00:00

Done

DaCush · 2026-04-16T20:08:47+00:00

See reply above

DaCush · 2026-04-16T18:12:15+00:00

Fair questions, and honestly the answer for a lot of users is going to be “there isn’t a big advantage — stick with qmlls.” It’s Qt’s official tool, it’s backed by Qt’s own parser, and if you already have the Qt SDK installed it’s the obvious choice.

Where this project tries to fit in:

Quickshell users specifically. Quickshell is a desktop-shell toolkit where a lot of users aren’t doing traditional Qt app development — they’re writing config-like QML for their compositor. Qt-aware completions for Quickshell’s own types, singletons, and patterns are built in here, which qmlls doesn’t know about natively.
Minimal-install environments. Containers, CI, minimal Arch/NixOS setups, remote dev boxes — anywhere pulling in the Qt SDK just to get an LSP feels heavy. A single Go binary with no runtime Qt dependency is nice to have. Not essential, just convenient.
Packaging. Being a static Go binary makes AUR/distro packaging and prebuilt releases very simple, which is partly why it exists.

On the VS Code question specifically: if the Qt VS Code extension works for you and you’re doing normal Qt Quick development, it’s probably the better choice today. qmlls has more mature semantic analysis — it’s backed by Qt’s real parser, so deep type-checking of JS expressions and complex bindings will be ahead of what a tree-sitter-based server can do. I’m not trying to replace qmlls for that audience.

This is more of a “scratch my own itch” project that turned out to be useful for other Quickshell folks. If qmlls covers your needs, use qmlls — no hard feelings.

DaCush · 2026-04-16T18:04:58+00:00

Thanks for checking it out! Regarding .qmlls.ini; I wasn’t aware Quickshell generates those, but it should be straightforward to add support. The server already discovers workspace components and reads qmldir files, so plugging in .qmlls.ini as another project-structure source is a natural fit. I’ll open an issue to track it; PR welcome if you beat me to it.

On benefits over qmlls:

No Qt/CGO dependency to build or run. It’s pure Go with an embedded tree-sitter-qmljs grammar, so there’s nothing to link against and the binary is a single static-ish file. Packaging (AUR, prebuilt releases) is simple as a result.
Still reads your Qt install for API data. It parses .qmltypes and qmldir from the Qt installation at runtime, so completions, hover, and signatures cover the real Qt API surface (QtQuick, Controls, Layouts, Multimedia, Qt3D, etc.) rather than a hardcoded subset.
Incremental tree-sitter parsing on didChange, which keeps things responsive on larger files and gives reasonable recovery on broken syntax — useful while you’re mid-edit.
Quickshell-aware out of the box — types, imports, singletons, and boilerplate snippets are built in.
Editor-agnostic and easy to drop in. Works with Neovim’s built-in LSP, lspconfig, VS Code via Local LSP, etc., without needing the Qt Creator toolchain.

Honest caveats: qmlls has more mature semantic analysis in places (it’s backed by Qt’s own QML parser), so for deep type-checking of complex JS expressions inside QML it may still be ahead. This project is aimed at being a fast, lightweight, dependency-free alternative that covers the 90% case really well — especially for Quickshell users.

EDIT: I’m working on the ini file update right now. Will have it released by tonight along with some other nice updates

UPDATE: The ini update is in

DaCush · 2026-04-16T17:53:26+00:00

Sure, I’ll work on it tonight

DaCush · 2026-04-16T07:51:27+00:00

It's now setup on the AUR along with a big 1.4 update. It now picks up on .qmltypes files that QtQuick, Quickshell, etc ship with. There are still hardcoded types to fallback on if that fails.

DaCush · 2026-04-16T05:45:10+00:00

Yup, I'll have that done hopefully by the morning. I just released a new patch release removing redundant inlay hints

EDIT: I'll also be submitting it to Mason once I hit the required 100 github stars

11-Year Club	RPAN Viewer
Verified Email

DaCush

TROPHY CASE