You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently compositors either have all input handling with an <I: InputBackend> generic, or manually repack the events (e.g. Catacomb). It doesn't really feel worth it to me to compile all input code three times (for libinput+winit+something like virtual input) and have it take up three times the space in the final binary.
While the main input backend trait and enum list all their event types as associated, the individual event traits only expose &self methods with simple types, all of which are already dyn-compatible. So maybe some not super major refactoring can be done?
It's important though to still be able to downcast things to the underlying type, especially to get to the real libinput device during event processing. But I believe downcast-rs should take care of that.
The text was updated successfully, but these errors were encountered:
Currently compositors either have all input handling with an
<I: InputBackend>
generic, or manually repack the events (e.g. Catacomb). It doesn't really feel worth it to me to compile all input code three times (for libinput+winit+something like virtual input) and have it take up three times the space in the final binary.While the main input backend trait and enum list all their event types as associated, the individual event traits only expose
&self
methods with simple types, all of which are already dyn-compatible. So maybe some not super major refactoring can be done?It's important though to still be able to downcast things to the underlying type, especially to get to the real libinput device during event processing. But I believe downcast-rs should take care of that.
The text was updated successfully, but these errors were encountered: