Add MacOS Support

[heyimcarlos]

Input flow native example with enigo crate has build errors on MacOS.

It contains a type on OSX only which is not send + sync.

To fix this, it must be wrapped in something like an Arc<Mutex<>> to maintain cross-platform build compatability.

[heyimcarlos]

I tried using the Mutex type to solve the cross platform issue, but still, the Send trait is not implemented by the event_source: CGEventSource type within the Enigo struct. So, the NonNull<core_graphics::sys::macos::CGEventSource> type still produces the error even after being wrapped in an mutex.

I first tried adding only a mutex:

#[derive(Debug)]
pub struct InputFlowNative {
    enigo: Mutex<Enigo>,
}

impl Default for InputFlowNative {
    pub fn default() -> Self {
        Self {
            enigo: Mutex::new(Enigo::new(&Settings {
                release_keys_when_dropped: true,
                ..Default::default()
            }).expect("Failed to initialize Enigo")),
        }
    }
}


// Error after adding Mutex: `NonNull<core_graphics::sys::macos::CGEventSource>` cannot be sent between threads safely within `Enigo`, the trait `std::marker::Send` is not implemented for `NonNull<core_graphics::sys::macos::CGEventSource>` required for `Mutex<Enigo>` to implement `std::marker::Send` [E0277]
impl MouseWriter for InputFlowNative { // <-- Error saying that the send trait is not implemented still persists
  fn send_button_down(&mut self, button: u32) -> Result<()> {
        if let Some(key) = keycode_to_button(button) {
            self.locked() // <-- added locking
                .unwrap()
                .enigo
                .button(key, Direction::Press)
                .map_err(|_| InputFlowError::SendError)
        } else {
            Err(InputFlowError::InvalidKey)
        }
    }
}

[heyimcarlos]

I found two possible ways to deal with this (which I don't fully understand):

1. Providing an unsafe implementation of Send to inform the compiler that you've taken into account the thread-safety of the objects behind the pointer (which we're doing, since we're using a mutex).

struct WrappedEnigo(NonNull<Enigo>);

// bypass Rust's default safety checks
unsafe impl Send for WrappedEnigo {}

// SafeType: This struct contains a Mutex<WrappedPointer>, ensuring that access to the WrappedPointer (and thus to the non-thread-safe RawType) is synchronized. The mutex provides thread-safe mutable access to the wrapped pointer.
struct SafeEnigo {
    inner: Mutex<WrappedEnigo>,
}

impl Default for SafeEnigo {
    pub fn default() -> Self {
        let enigo = Enigo::new(&Settings {
            release_keys_when_dropped: true,
            ..Default::default()
        })
        .expect("Setting up enigo");
        let ptr = NonNull::new(enigo).expect("Non-null expected");
        Self {
            inner: Mutex::new(WrappedEnigo(ptr)),
        }
    }
}

 impl KeyboardWriter for SafeEnigo { // <-- no error since the `Send` trait is unsafely implemented
    fn send_key_down(&mut self, button: u32) -> Result<()> {
        if let Some(key) = keycode_to_button(button) {
            let enigo_mutex = self.inner.lock().unwrap();
            unsafe { // <-- have to use unsafe here because dereferencing a raw pointer in inherently unsafe in Rust
                enigo_mutex
                    .0
                    .as_ref()
                    .button(button, Direction::Release)
                    .map_err(|_| InputFlowError::SendError)
            }

        } else {
            Err(InputFlowError::InvalidKey)
        }
    }
}

2. Instantiating the Enigo instance inside functions/callbacks (where consumed)

Example coming from enigo issue 96

move |stamp, message, _| {
            let keystroke = Enigo::new(); // moved the instantiation to this place
            println!("{}: {:?} (len = {})", stamp, message, message.len());
            if message[0] == 144 && message[1] == 60 {
                keystroke.key_sequence_parse("{+META}{-META}");
            }
            println!("{}: Matched MIDI input, sending configured keystroke", stamp)
        }

[ConnorBP]

I found two possible ways to deal with this (which I don't fully understand):

1. Providing an unsafe implementation of Send to inform the compiler that you've taken into account the thread-safety of the objects behind the pointer (which we're doing, since we're using a mutex).

struct WrappedEnigo(NonNull<Enigo>);

// bypass Rust's default safety checks
unsafe impl Send for WrappedEnigo {}

// SafeType: This struct contains a Mutex<WrappedPointer>, ensuring that access to the WrappedPointer (and thus to the non-thread-safe RawType) is synchronized. The mutex provides thread-safe mutable access to the wrapped pointer.
struct SafeEnigo {
    inner: Mutex<WrappedEnigo>,
}

impl Default for SafeEnigo {
    pub fn default() -> Self {
        let enigo = Enigo::new(&Settings {
            release_keys_when_dropped: true,
            ..Default::default()
        })
        .expect("Setting up enigo");
        let ptr = NonNull::new(enigo).expect("Non-null expected");
        Self {
            inner: Mutex::new(WrappedEnigo(ptr)),
        }
    }
}

 impl KeyboardWriter for SafeEnigo { // <-- no error since the `Send` trait is unsafely implemented
    fn send_key_down(&mut self, button: u32) -> Result<()> {
        if let Some(key) = keycode_to_button(button) {
            let enigo_mutex = self.inner.lock().unwrap();
            unsafe { // <-- have to use unsafe here because dereferencing a raw pointer in inherently unsafe in Rust
                enigo_mutex
                    .0
                    .as_ref()
                    .button(button, Direction::Release)
                    .map_err(|_| InputFlowError::SendError)
            }

        } else {
            Err(InputFlowError::InvalidKey)
        }
    }
}

2. Instantiating the Enigo instance inside functions/callbacks (where consumed)

Example coming from enigo issue 96

move |stamp, message, _| {
            let keystroke = Enigo::new(); // moved the instantiation to this place
            println!("{}: {:?} (len = {})", stamp, message, message.len());
            if message[0] == 144 && message[1] == 60 {
                keystroke.key_sequence_parse("{+META}{-META}");
            }
            println!("{}: Matched MIDI input, sending configured keystroke", stamp)
        }

If we can determine that the API calls used have no requirement of being called from the same thread always, then we should be able to unsafe impl Send. Otherwise we should rely on a dedicated thread and a message passer (mpsc) for our implementation.