Crate Maintenance

[TTWNO]

Hello @Narsil ,

rdev is very useful to me and many others. However, the piling up of PRs and issues has me wondering if this crate is going to continue to see maintenance?

I am absolutely willing to step up with time, code reviews, writing tests, etc. to make this happen.

• If you don't have time and want to abandon this crate, please let one of the larger contributors (or myself) take over so we can continue the development without forking.
• If you do have some time, please tell me what the most urgent needs are, and I'll starting writing/reviewing PRs for them. As long as upstreaming new code is still possible for you, I think we can make a good effort doing this.

Your crate has over 150,000 downloads and indirectly used by over 2,000 projects; it's clearly extremely useful! We just want to be able to use one crate instead of having over a hundred forks with slight variation.

[bogzbonny]

That's awesome @TTWNO I'm curious as to how involved @Narsil wants to be, I know sometimes devs (including myself) will have very active periods of time followed by long lulls (sometimes taking years off projects, but then coming back with lots of energy!). I hope Narsil gets back here and is willing to make somebody who's interested in this stuff a maintainer on the main branch here, they're clearly still doing stuff on github.

I think a reasonable solution is to soft-fork this project (rdev2?), become the primary maintainer, pulling as much of the PRs as seems reasonable and just rolling with the codebase.
Hopefully Narsil becomes responsive and the fork can be merged in, otherwise eventually that project would become "disconnected" and turn into a hard-fork (hopefully it doesn't come to that).

I'm using this project right now in https://github.com/bogzbonny/macronizer and there are a few features I need which I'd be willing to contribute on:

1. getting proper closedown to the listening loop (there are a couple of other issues relating to this, and a closed PR)
2. Keyboard event consumption - for re-assigning certain keystrokes it would be nice to be able to have the option of capturing certain keyboard keys and preventing keystroke propagation, allowing for my program to then propagate other keystrokes in replacement of the one which was actually typed.

If you are willing to put in some maintenance, I'd much rather work on these features on an up to date fork with an active maintainer, I spend an hour or so digging through all the different PRs and forks attempting to figure out what the idea "HEAD" would be, unfortunately there is a lot of disjointed work, including people doing some forking on other forks (lol). I'm also willing to help/lead with maintenance on this repo or a forked rdev2

[bogzbonny]

oops looks like (2) is already actually implemented https://docs.rs/rdev/latest/rdev/#grabbing-global-events-requires-unstable_grab-feature

[pentamassiv]

I'm the maintainer of enigo. So far I've been focusing on properly implementing input simulation, but I think the biggest issues will be fixed soon. I am interested in adding listening/grab capabilities to my crate. I would welcome contributions :-)

If someone ends up taking over the maintenance of rdev, feel free to ping me so we can maybe work together on some topics such as running integration tests.

[SylvanFranklin]

I'm also wondering about this. Currently one of my projects that requires this crate has broken with an OS upgrade

[Narsil]

Hey, I was indeed off of this crate for quite a long time, because I just didn't need it anymore.

Simple library to listen and send events globally to keyboard and mouse on macOS, Windows and Linux (x11).
You can also check out Enigo which is another crate which helped me write this one.
This crate is so far a pet project for me to understand the Rust ecosystem.

I guess my disclaimer wasn't strong enough.

Overall I still think enigo should be the prefered crate for anything global.

@TTWNO @bogzbonny thanks a lot for the proposal to help, that's really appreciated.
Any help in reviewing/testing existing (remaining) PRs is appreciated.
The hardest part of merging anything is making sure:

• The API works, and is consistent across ALL OSes (I just broke this on main with x11/wayland, but I'm really struggling to figure out solutions on stuff in wayland where basically all basic operations require do dabble with all compositors, no release will happen until I figure it out.)

I am definitely willing to bring other people as maintainers, and I think that person would need to show the same care for all 3 OSes.

I've seen quite a lot of PRs being open that target only 1 OS out of the 3, mostly pushing into fracturing the API instead of keeping it united (which is honestly the only reason for this crate to exist, if you target only 1 OS there's absolutely no need to use this weird API).
In the same sense, a lot of PRs/forks are just broken.

[qzd1989]

enigo uses core_graphics::sys::macos::CGEventSource which cannot be sent between threads safely... so....enigo-rs/enigo#436