Robert Bragg

As a caveat it's notable that since we are strictly required to explicitly detach from native threads before they terminate then we probably do at least need to keep the...

Besides considering whether we could remove `AttachGuard`, as above, I think my inclination here would also be to make the `attach_current_thread` APIs themselves `unsafe` instead of having them return an...

I've opened this alternative draft PR that overlaps with the changes proposed here - it would be great to get your thoughts @argv-minus-one : https://github.com/jni-rs/jni-rs/pull/570

The issues with thread attachment safety have hopefully been addressed in #570 :crossed_fingers:

Things did pick up a bit recently with a lot of work going on towards https://github.com/jni-rs/jni-rs/pull/570, but essentially the project has been fairly dormant over the last few years. The...

Hi, again, sorry for the delayed follow up. I've done quite a lot of work on the `jni` crate recently and am hoping it's more-or-less ready for a 0.22 release....

Thanks, I've just merged your PR for making static_assertions a dev-dependency. As I've been updating android-activity and my bluey crates based on the release-0.22 branch I've ended up making some...

Not sure if this might be a handy reference for checking what we do in the Windows backend atm: http://www.petergiuntoli.com/parsing-wm_input-over-remote-desktop

This line at least looks like it's probably wrong: https://github.com/rust-windowing/winit/blob/47488909353bb6d8e52801b8824b0e2352e4ab63/src/platform_impl/windows/event_loop.rs#L2393 `MOUSE_MOVE_RELATIVE` isn't a flag that can be masked, it equals `0` so considering `util::has_flag` is a utility for `bitset &...

I guess we want something like this: ```rust // WARNING: Don't try and test `MOUSE_MOVE_RELATIVE` as if it's a flag // because it equals zero and `has_flag` would unconditionally //...