Replace EventLoopWindowTarget with ActiveEventLoop

[madsmtm]

This is done for several reasons:

• To in the future allow restricting window creation to ActiveEventLoop (which resolves a bunch of long-standing issues on macOS and iOS).
• To avoid the Deref on EventLoop, which is discouraged by the C-DEREF guideline.
• To allow further flexibility in each platform, as we are now no longer required to store crate::event_loop::EventLoopWindowTarget in the platform's own EventLoop.
  • At some point we could perhaps even change ActiveEventLoop to contain &mut.

Blocked on #3298.

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality
• Updated feature matrix, if new features were added or implemented

[daxpedda]

Let me know if I can help out here, happy to do the rebase.

[madsmtm]

Unsure about:

• MaybeActiveEventLoop being the best design, but not sure what else we could do?
• CustomCursorBuilder::build, which kind of event loop should it take?
• EventLoopExtStartupNotify implemented on both kinds of event loop.

[daxpedda]

• MaybeActiveEventLoop being the best design, but not sure what else we could do?

Do we even need traits like that? It's not even less code for us and I'm not sure what users gain out of this.

• CustomCursorBuilder::build, which kind of event loop should it take?

I don't know what the lowest common denominator is, but for Web either event loop is fine.

[madsmtm]

MaybeActiveEventLoop being the best design, but not sure what else we could do?

Do we even need traits like that? It's not even less code for us and I'm not sure what users gain out of this.

It's mostly meant as an intermediary, until we feel confident in disabling user's ability to create windows from outside the running event loop.

But before I feel that we can make that change, it must be easy for them to do the correct thing, and that basically requires #2903.

[daxpedda]

MaybeActiveEventLoop being the best design, but not sure what else we could do?

Do we even need traits like that? It's not even less code for us and I'm not sure what users gain out of this.

It's mostly meant as an intermediary, until we feel confident in disabling user's ability to create windows from outside the running event loop.

What I meant to say is that we can just implement these things as methods on EventLoop and ActiveEventLoop directly, they don't have to live in a trait. Whats the use-case exactly for being generic over these two?

[madsmtm]

Whats the use-case exactly for being generic over these two?

None other than keeping Window::new(event_loop) working. If we don't want that, but are fine with event_loop.create_window(window_builder), then there is no need for the trait.

[daxpedda]

Whats the use-case exactly for being generic over these two?

None other than keeping Window::new(event_loop) working. If we don't want that, but are fine with event_loop.create_window(window_builder), then there is no need for the trait.

Right ... sorry ... brain-fart. Now it makes sense 😅!
I'm fine with keeping the trait then, I don't mind removing it either but we can do that in a follow-up.

[daxpedda]

Replaced with #3447.