[WIP] Add wasm32-unknown-unknown support through stdweb

[ryanisaacg]

• stdweb APIs (there a couple web APIs used in the emscripten backend that aren't yet available)
  • DPI
  • Pointer lock
  • Main loop
    • Interrupt the main loop when necessary
    • Set the main loop (stdweb callbacks must be 'static, but winit callbacks have no such restrictions
  • Touch events
  • Fullscreen
  • Show / hide mouse
• Delete callbacks when the window is dropped
• 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 an example program if it would help users understand this functionality

[francesca64]

Comment out the main loop until a good solution to the 'static problem

Changing the closure to be 'static is actually included in the plans formulated in #459, which is certainly recommended reading.

[ryanisaacg]

Followed the recommendation and did some reading, very interesting!

Funnily enough, yielding control of the main loop and only getting called back from the browser is what I've done with quicksilver. If winit adopts this model it would make my life much easier! 😄

Should I delay work on this backend until EventLoop 2.0? And can I help with EventLoop 2.0?

[francesca64]

Should I delay work on this backend until EventLoop 2.0?

That's what I'd recommend, since having people waiting for me is the only way I'm going to be able to motivate myself to implement EventLoop 2.0.

And can I help with EventLoop 2.0?

I'm not familiar with Emscripten at all, and the discussion in #459 makes it clear that there are important details, so if you're able to migrate that backend it would be a big time save.

As it stands, @Osspial (who claimed the Windows backend for this rewrite) hasn't been around, and @vberger (who does all the Wayland stuff) has been busy. So, by default I'm the one handling all of the backends... I actually don't think that's too much of a problem, but it's undeniably going to be time consuming.

I've also been working on gamepad support, though what order all of this will happen in is anyone's guess.

[ryanisaacg]

I'm only familiar with emscripten inasmuch as I know the web APIs it interfaces with, but I'll be happy to pitch in and try to learn.

For the gamepad stuff, are you going to be integrating / working off of the gilrs crate? I've been meaning to look into getting Mac and web support started for it, but it's slipped my mind.

EDIT: just saw you on the issue tracker for the project, I guess I don't need to work on gamepads for Mac after all 😄

[iceiix]

Trying to see if this can be updated... besides the merge errors (divergence in winit from this branch), getting this compile errors. Note Cargo.toml uses a git version of stdweb, is it now incompatible?

winit $ cargo install cargo-web
winit $ cargo-web build --example window --target wasm32-unknown-unknown
error[E0425]: cannot find function `set_main_loop_callback` in this scope
   --> src/platform/stdweb/mod.rs:158:9
    |
158 |         set_main_loop_callback(|| {
    |         ^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
error[E0310]: the parameter type `F` may not live long enough
   --> src/lib.rs:248:26
    |
245 |     pub fn run_forever<F>(&mut self, callback: F)
    |                        - help: consider adding an explicit lifetime bound `F: 'static`...
...
248 |         self.events_loop.run_forever(callback)
    |                          ^^^^^^^^^^^
    |
note: ...so that the type `F` will meet its required lifetime bounds
   --> src/lib.rs:248:26
    |
248 |         self.events_loop.run_forever(callback)
    |                          ^^^^^^^^^^^

error: aborting due to 2 previous errors
Some errors occurred: E0310, E0425.
For more information about an error, try `rustc --explain E0310`.
error: Could not compile `winit`.

[ryanisaacg]

@iceiix This was very much in-progress but I've stopped work on it until EventsLoop 2.0 API is done.

[seivan]

Can I come with a suggestion since you're working on this: Please add the locations for clicks/touch events instead of letting the user to store state to manage them.

Right now I gotta do

                  ElementState::Pressed => {
                      .....
                    }
                    ElementState::Released => {
                     .........
                    } 

Read in the last state (values) from WindowEvent::CursorMoved
It's not the best design, and afaik SDL2 gives locations as well - not sure if Winit is constrained in anyway preventing this.

[ryanisaacg]

Closed in favor of #797