Feature: Simpler syntax like Simulate_key crate

[vtempest]

Is your feature request related to a problem? Please describe.
Complex boilerplate & key codes

Describe the solution you'd like

https://crates.io/crates/simulate_key

use simulate_key::simulate_key;

fn main() {
    // Basic key combinations
    simulate_key("ctrl+c").unwrap();
    simulate_key("alt+tab").unwrap();
    simulate_key("ctrl+shift+t").unwrap();
    
    // Function keys
    simulate_key("f5").unwrap();
    simulate_key("ctrl+f12").unwrap();
    
    // Navigation
    simulate_key("ctrl+home").unwrap();
    simulate_key("shift+end").unwrap();
    
    // Single characters
    simulate_key("a").unwrap();
    simulate_key("enter").unwrap();
    
    // Hold keys
    use simulate_key::simulate_key_hold;
    simulate_key_hold("space", 500).unwrap(); // Hold space for 500ms

Error Handling

match simulate_key("invalid+key") {
    Ok(()) => println!("Key simulated successfully"),
    Err(e) => println!("Error: {}", e),
}

Describe alternatives you've considered

https://crates.io/crates/simulate_key

Additional context
Add any other context or screenshots about the feature request here.

[pentamassiv]

It's great to see that you took initiative and tried to improve enigo! Unfortunately I don't think I will add your proposed syntax to enigo for now. My main goal is to resist feature creep to keep the crate maintainable. There are so many weird quirks to take care of just to get everything to work. I cannot take on more work. It's difficult to get the abstractions right to hide the differences between the platforms and the situation on Linux when it comes to X11, Wayland and libei doesn't make it any easier. I think it is better for me to try to get enigo to work correctly and be type safe. Others can build crates on top of it to experiment with the syntax quite easily (just like you did). I can then merge stuff if they don't come with any downsides.

Your syntax is more ergonomic, but there are issues with it. There are of course possible solutions to these issues and I encourage all experimentation and attempt to improve the current situation. Please don't be discouraged by the following list. I am trying to point you to issues I encountered over the last couple of years so you don't have to make them.

The main issue is that there are reasons for the enigo struct. Unfortunately there is a need to track state. On macOS for example you need to track the state of the event_flags. Enigo also takes care of simulating a mouse. On macOS you need to count the time since the last mouse click to properly simulate double clicks. There are many more reasons for the state tracking. I encourage you to look at the Enigo struct and its fields to better understand the issue. In your crate, you create the Enigo struct for each call of simulate_key and drop it afterwards. That resets the state each time and breaks the previously mentioned functionality. I guess you could somehow make sure the struct gets created with the first call of a function from your library and all other calls reuse it. You will have to wrap it so it can be used from multiple threads as well. This comes with a performance cost.

It can also take quite some time to create the Enigo struct, so your calls will be much slower. That might not be important to you, but my goal with enigo is to make it as fast as possible so it can be used in applications where it matters as well.

You will also run into problems if your library is used with Tauri, because on macOS, the functions to simulate a key need to be called on the main thread. To be fair, that is still an issue on enigo as well (#436), but it is at least possible to avoid it. Once a fix is implemented in enigo, it should work with your crate as well so this hopefully is a temporary problem.

Another downside of your implementation is the lack of type safety. You have to run the code to find out that a key does not exist. It also is less efficient, because you need to parse the string each time. I don't see how you could fix that. I think that's something users of your crate would have to live with.

I am sure you know this, but for completeness: The simulate_key_hold function blocks all execution since there is just a sleep for the specified duration. I avoided having to deal with this problem, because I don't know if that is an issue, a desired behavior or it doesn't matter to the users. They might be okay with it or they might want to use threads or async functions to not block while holding a key.

Again, I appreciate your suggestions and feel free to ask me as much as you'd like to about enigo and the reasons for its implementation. I'll close the issue for now since I don't plan on working on it. I'll keep an eye on your crate though and hope that many people will find it useful.