How long till the promised JavaScript runtime (Resonance)

[random-programming-guy]

I am personally a great admirer of ydotool, it's the only way of gui automation in wayland.
Today reading the offical docs I see that ydotool was about to release it's ultralight JavaScript Resonance in second half of 2024.
Since I am a javascript developer and looking forward to use this in some projects of mine, i wish you could give some updates about when is it releasing.
i can contribute too btw

[ClassicOldSong]

Creating a runtime is way harder than you think.

We're still moving slowly to there, but it's closer to done than ever.

When it's done, you'll be able to contribute the JavaScript implementation part of ydotool.

Although I don't want to say this, but this is an open source project and we get almost nothing from it, and we've been in negative income for years working on this runtime, so nothing is actually promised. It's unhealthy to take "promises" seriously on anything you haven't paid for, especially on open source projects, where free maintenance can be a burden to the creators in certain situations. Hope this doesn't offend you.

[ReimuNotMoe]

i wish you could give some updates about when is it releasing

We're working on this everyday. But we only have 2 people so it's going to take a really long time. I hope we can release a preview version later this year.

[fbaltor]

Any way for you to open this so we can help?

[danya02]

Good luck on the runtime! I've often said that we need a lightweight alternative to NodeJS or Deno if we keep writing CLI apps in JS.

That being said, I'm not sure why this specific project needs it. From a cursory look at the code, it seems that the daemon only sets up the listening socket and forwards messages to /dev/uinput without any modifications, and the client also just converts the CLI arguments into input_event structs in a fairly trivial way. The code is very readable, reliable, and the only possible improvement I could suggest is to maybe use special-purpose structs to represent requested commands.

To my mind, the code is both very understandable, and is also mostly done, so it requires few contributions.
But in your README, you say you want to rewrite "to enable more people to understand the code & contribute" -- could you explain why you feel like this is a problem?

[ClassicOldSong]

Linux lacks something like AHK for long and we hope this can fill the gap

[danya02]

That's a good goal, but that only really requires that you have a scripting language available to the user. I feel like this might be easier done by giving us access to the control socket instead. You can make a JS library that has some helpers for constructing the input_event struct (and maybe parsing incoming events if you have and/or make any), and just connect it to the existing daemon.

You can then ship a program to run these JS scripts with your runtime, but also let others use their own runtime or language. I happen to like Rust (and I feel like that's a better choice for this project, but that's besides the point), and I'm writing my own input automation app using https://github.com/enigo-rs/enigo, but I could just as well use the ydotool daemon as the backend for input emulation if I knew the command format is going to be stable.