Listen to User Events about enigo HOT 16 OPEN

I worked on something like this to see how we could do Cross platform rust.

https://github.com/Narsil/rdev

It's not compatible with Enigo because I stayed lower level (only raw keycodes for now) but it might be handy for ppl that want to include it in Enigo.

Main caveat, on MacOS you need to be a main app to be able to listen to events AND have enabled accessibility for Terminal or the name of the app. Cheers.
Edit: I didn't do windows code because I don't have access to one right now.

from enigo.

mentioned about that making it blocking, that's not acceptable in some use cases.
we can provide both, something like this:

The idea is that if the underlying api is blocking, then we should not use threads to make it not so. Especially not call it "async" if it's not actually async but rather using threads.

from enigo.

Currently there is no way to listen to events with enigo. We're thinking about it but don't expect this to happen anytime soon because this is a quite involved task to do cross platform and would possibly involve some async system (tokio-'core'?). I just don't have a clear vision about this topic currently.

from enigo.

Seems to be possible on Linux X11 (not with libxdo sadly) to have an event loop, on windows it seems limited to hotkeys, which may be sent to either a window or a thread-local event queue. For mac, I have no idea

from enigo.

@jD91mZM2 how do you think this should be handled from the user perspective? having a register method the that takes a closure? and in the background we start a thread and run an event loop – or somehow try to use tokio stuff?

from enigo.

@pythoneer Since most operating systems' APIs are blocking, I'd suggest we make it blocking as well, and if the user wants it concurrent use threads

from enigo.

@jD91mZM2 this sounds right for now. I was concerned about starting threads because i don't think the user expect that to happen and you don't just start threads out of nowhere. But how should a blocking API should look like for a use case where you want to "register" multiple events?

from enigo.

enigo.register_event(Key::ESC);
for event in enigo.events() {
    let event = event?;
    // do something with event
}

from enigo.

Ok, just like SDL etc..

from enigo.

Just my idea, seems like the cleanest

from enigo.

looks about right. I think the user can expect it to look like this coming from SDL, win32, or from any other input event handling background.

//EDIT:

I was just thinking about something like

enigo.register(Key::ESC, |evt| println!("escape pressed"));

but i think this is just to problematic

from enigo.

after some googling, just found some good crates that maybe useful
https://github.com/obv-mikhail/InputBot
which i just tried and it works fine*
and also https://github.com/autopilot-rs/autopilot-rs which seems interesting too, as it works with python too https://github.com/autopilot-rs/autopy

if we can have an API as @pythoneer proposed i think it will be good too.
and as @jD91mZM2 mentioned about that making it blocking, that's not acceptable in some use cases.
we can provide both, something like this:

// Call this to start listening for bound inputs.
handle_input_events();

// or async
handle_input_events_async();

anyway i'm ready to help, just make a new issue with a Check list, and we can make it together.

• inputBot works great but seems sometimes have some problem about toggling buttons.

from enigo.

There are two functions in Mac

• InstallEventHandler (Carbon)
• addGlobalMonitorForEventsMatchingMask (Cocoa)

Mac global hotkey in Swift (Carbon)

• https://github.com/Clipy/Magnet

from enigo.

Is there a WIP on this topic? I'm ready to help too.

from enigo.

@bnau i think no one has actually started a serious effort in this direction as of now.

from enigo.

@pythoneer Okay, thx.
I will fork the project and make a PR as soon as something is ready.
Any idea/suggestion/contribution is welcome!

from enigo.