Begin transition to a trait-based system #3386
Conversation
the `EventLoopWindowTarget` is needed for window creation. conceptually, only `EventLoop` and `EventLoopProxy` need to be parameterized, and all other parts of the backend should be agnostic about the user event type, parallel to how `Event<T>` is parameterized, but `WindowEvent` is not. this change removes the dependency on the type of user events from the `EventLoopWindowTarget` for the Windows backend, but keep a phantom data to keep the API intact. to achieve this, I moved the `Receiver` end of the mpsc channel from `ThreadMsgTargetData` into `EventLoop` itself, so the `UserEvent` is only passed between `EventLoop` and `EventLoopProxy`, all other part of the backend just use unit type as a placeholder for user events. it's similar to the macos backend where an erased `EventHandler` trait object is used so all component except `EventLoop` and `EventLoopProxy` need to be parameterized. however `EventLoop` of the Windows backend already use an `Box<dyn FnMut>` to wrap the user provided event handler callback, so no need for an dedicated trait object, I just modified the wrapper to replace the placeholder user event with real value pulled from the channel. I find this is the approach which need minimum change to be made to existing code. but it does the job and could serve as a starting point to future Windows backend re-works.
this field is transitional and her to keep API compatibility only. the correct variance and such is already ensured by the top-level `EventLoopWindowTarget`, just use `PhantomData<T>` here.
madsmtm
added
S - api
madsmtm
changed the title
ApplicationHandler, WindowHandler)ApplicationHandler, WindowHandler, ...)
madsmtm
changed the title
ApplicationHandler, WindowHandler, ...)
|
Concretely, because we can ship this to users in And then we can work on removing (But I get that we differ in views on this). |
|
I don't want for users to have more work upgrading to incomplete API and then to complete one, I as downstream project maintainer I won't waste my time on such mess. |
|
I don't see your issue as a downstream user? Regarding |
|
The thing about my API is that it's not complete because I was asked to wait, more things will change, like surely you can port some of that work, but I can't really deal with return values on Wayland because the don't make any sense to me since everything is queued, so the main motivation to return values is completely lost. And the whole return is blocked for me because |
|
The same issue with neovide since I can't solve their sync issues unless I just do the full design and |
madsmtm
force-pushed
the
active-event-loop
branch
7 times, most recently
from
2e1dc24 to
5f4430e
Compare
|
Superseded by #3517. |
Part of #3367. Blocked on
#3299#3447, since I want to keep the active handle being passed around as simple as possible.Add a trait
ApplicationHandler<T>which replaces the closureimpl FnMut(Event<T>, ActiveEventLoop<'_>)matching onEvent<T>s. This trait is fully compatible with the closure, and all backends and most examples still use the old event design. But it should be possible to slowly migrate things from here.Note that this will not be the final design of the trait,
exitwill probably be replaced byDrop(you shouldn't need to access theActiveEventLoop<'_>from there anyhow, and it's more "Rusty"), we'll probably introduce a closure at the beginning instead ofinit, there are events that should be changed to have return types, and so on.But we need to keep these APIs around mostly as-is, so that we can convert between the trait and the closure, at least until we've gathered experience, and are ready to remove the closure-based API.
TODO:
WindowHandlerin this PR too).runfunction, as discussed previously.Note: This PR is similar to my earlier #3073, but differs in that it doesn't try to do anything fancy with the event lifecycle yet, and that it has the full two-way compatibility between trait and closure.