Add accesskit_adapter crate. Upgrade accesskit_winit to winit 0.31.0-beta.2

[nicoburns]

• Fixes Request: Winit 0.31 support #654

Motivation

• Upgrade AccessKit's Winit support for Winit 0.31 (currently in beta)
• Create a cross-platform AccessKit adapter that can be used without Winit
• The non-winit cross-platform adapter would also be useful for using AccessKit with new versions of Winit before Accesskit adds support.

Changes Made

• Create a new accesskit_adapter crate that abstract accross the platform adapters without depending on Winit types
• Make accesskit_winit a thin wrapper around accesskit_adapter
• Update accesskit_winit to Winit 0.31.0-beta.2. Notably Winit 0.31 no longer has a generic user event type. The expectation is that users of Winit will send their own events via a side channel such as a std::mpsc channel. I have therefore updated accesskit_winit to accept a generic callback.

[DataTriny]

Hi @nicoburns, thank you for this. Unfortunately I don't think winit 0.31 will be released soon.

We will want to bump our MSRV once we update winit, but I'd prefer a separate commit for this. Note that I would not merge it until it is required by winit.

I am really unsure about introducing yet another crate. The subclassing adapters are a hack, so I'd prefer to keep their use limited to where they are needed. Depending on how the NSView is setup, there may even be more to do on macOS so it is dangerous to expose a generic API with this. Hopefully winit can give us the necessary hooks at some point and we can use the proper adapters for this library.

[mwcampbell]

I also disagree with breaking out the winit platform backend abstraction into an accesskit_adapter crate. It bakes in some assumptions, like the use of the Windows and macOS subclassing adapters and the use of android-activity, that aren't universal and shouldn't be treated as such. I'd rather have those assumptions right in front of us whenever we work with winit. Hopefully we won't have to use the subclassing adapters forever. And we shouldn't automatically inherit those assumptions when we integrate AccessKit with another cross-platform windowing abstraction.

[nicoburns]

For what it's worth, the motivation for the cross-platform crate that doesn't directly depend on Winit is so that I can use it with Winit betas. For Blitz, we probably want to upgrade to Winit 0.31 while it's still in Beta, and my assumption is that y'all won't want to put out new accesskit_winit releases for every Winit beta.

If you don't want it upstream, then that's fine. I'll probably just publish it as a 3rd-party crate. It's not all that much code. And I guess I'll leave this PR here, as it will probably be useful as and when you do come to upgrade to Winit 0.31.

Long-term, I'd definitely be interested in learning about the more correct ways to implement things. And what would be needed for Winit and/or other backends to implement those.

[DataTriny]

If your current use case is within Blitz, couldn't you just copy the necessary code over there while we wait for winit 0.31? As you said, it's not a lot of code afterall. We have good reasons to not want a generic crate as proposed here so please think twice before publishing something you might not fully understand.

Thanks for the code though, it will be useful when the time to update comes.