daxpedda
daxpedda
> I would prefer having wider browser support. You can do runtime support detection, we have done this in [Winit](https://github.com/rust-windowing/winit/blob/f5dd1c008ceb13309d98eb1333b56bc92f973ace/src/platform_impl/web/web_sys/schedule.rs#L163-L183).
We have recently discussed on Matrix to remove `DeviceEvent::Motion`. Its unclear exactly what kind of information it provides and its not clear exactly how backends should implement it in relation...
In QUIC streams are free, opening a stream does literally nothing without sending a message. `r#type` is horrible I agree. Let's discuss this in more detail over voice today.
Rejection could be done by simply dropping the handle. The integer value isn't something supported by QUIC, you can close the stream with an integer, but the sender can't see...
I think as a more general solution, it would be best if we start by support defining `Symbol`s on `wasm-bindgen` exported structs. This would not only help users, but also...
> > I think as a more general solution, it would be best if we start by support defining `Symbol`s on `wasm-bindgen` exported structs > > That's a good point....
This could be easily added to the [list of Rust keywords](https://github.com/rustwasm/wasm-bindgen/blob/3a8da7cb8842d4cb9918871179b6b7d3c77df5a0/crates/backend/src/util.rs#L18), but unfortunately it requires much more plumbing to generate duplicate methods to avoid a breaking change. I'm happy to...
> If you can point me somewhere to getstarted on learning it, I would be willing to look into it. I don't think we have any documentation on the internal...
I'm not really a big fan of *replacing* `AffinePoint` and `ProjectivePoint` with an enum, but I think *adding* the enum would be great. Just wanted to leave a note here...
I also propose adding the same for `NonIdentityPoint`. We would have to figure out what to do with the naming conflict, unless we split the current `NonIdentityPoint` into two types...