[WIP] Macos Evlp2

[goddessfreya]

I kind of fucked up and had to manually back port changes. Git is hard. It will all get squashed in the end, so doesn't matter.

I think this is correct, or maybe not. All I know is it compiles :)

[goddessfreya]

cc @ryanisaacg

[goddessfreya]

I don't even know why it pulled in the x11 things, and I don't know how to fix it.

[Osspial]

I've got basically no knowledge of how cocoa works nor an ability to test stuff, so unfortunately I'm unable to review this.

[ryanisaacg]

I've checked the window example and the printed events look right, resize works, multiwindow works, min_max_size works, monitor_list works, etc. For now it looks good to me!

Once glutin supports events loop 2.0 and once I move Quicksilver over to events loop 2.0, I can test to see if it introduces any regressions there.

[goddessfreya]

@ryanisaacg You're in luck: rust-windowing/glutin#1146

Windows also compiles. Maybe you could test that, @Osspial ?

[ryanisaacg]

Having ported Quicksilver to EventLoop 2.0, I can pretty confidently say the macOS backend works.

[goddessfreya]

Splendid. Ready for merge, @Osspial, or do you have any objections?

[Osspial]

Nope. As a side note, this means that all the desktop backends for EL2.0 are done! 🎉 🎉 🎉

I'd like to address #728 and #794 before it gets onto crates.io, but.... yeah. Good work, everyone. It's been a long time coming.

[elinorbgr]

Question though, did this PR include the backport of the changes made to the master branch since it diverged with eventloop-2.0 ?

[goddessfreya]

I had to backport the following manually:
9a23ec3
45a4281
bfbcab3

The rest (checked every commit since 2018 which touched the macos files) were already included, assuming I didn't make a mistake and miss something.

@Osspial What's the plan wrt the mobile backends, and emscripten?

[Osspial]

I want to get the iOS backend merged since... well, it exists and works, but I'd like @mtak- to submit a PR for that since they wrote it. Other than that, I don't think Android and Emscripten are used widely enough to block the crates.io release, especially since we don't have anyone working on them at the moment - ideally they'd be included, of course, but it'll simplify the maintenance drastically to just have all the development be against master instead of having two active branches.

Also, I'd be comfortable with blocking the release on #797 depending on the timeline for getting that done. Don't have much of a sense for that, though. (cc @ryanisaacg)

[ryanisaacg]

At this point I'm mostly working on additions to stdweb to support features winit needs, which means that I'm largely bottlenecked on getting those changes merged and released. I'm not sure how long that will take, so if I start holding up the release I would say go ahead without web.