General recommendations and issues

[makepaddev]

Hi Winit community,

I've been building a Rust Wasm cross platform editor UI (demo makepad.github.io/makepad/ repo github.com/makepad/makepad), and i still have Winit as a dependency in it for linux but i'm removing it as i progress because of general stability and features missing. I compile cleanly to wasm32/unknown/unknown without emscripten. However since i think winit is a very useful thing for the Rust space i thought i'd collect all my issues and gripes with it in one post where i have solution in my codebase.

Bugs:

• 1 out of 5 startups on mac my mouse down events didnt work at all (dont know why).
• Window resize events on windows seem to be arriving much faster than i can draw causing a lag in the window resize
• IME support on mac just did nothing, half implemented it seemed

Missing features i implemented for makepad (solutions in my codebase):

• Wasm32-unknown-unknown support
• Platform timer events (timeout,repeat) NSTimer, WM_TIMER and such. (atm mac only)
• Posting a user-event to the message queue from another thread (atm mac only)
• A 'block or not' bool on the event api, not have 2 different poll calls (see https://github.com/makepad/makepad/blob/master/render/src/cx_mtl.rs#L211(
• Web compatible clipboard support API that also works on (web/mac only atm)
• Same keyboard input method as web (so no virtual key translation please)
• Web compatible text-input API with IME support (web/mac only atm)
• No 'outside of window mouse delta only', weird winit feature i fail to see the point of.

All of these features are implemented in my codebase and if anyone working on winit needs a reference or a place to copy from or see how web compatibility was managed, feel free to take anything its all MIT.
Currently on my todo is to replace winit entirely and implement Linux and Win32 directly on platform APIs, but that will happen in the next few months so implementations for those platforms of the above features will arrive as well.

As i have such specific finegrained requirements for my platform abstraction and winit seems so far away from what i want/need i don't want to go back to using winit myself or make pull requests, but maybe i can provide a reference to implement some of these features along the way instead.

Goodluck on the project and thanks for providing a reference for me how to interact with platforms from Rust!

[Osspial]

Hi!

We've been hard at work addressing several of your problems, actually! Check out the eventloop-2.0 branch if you'd like to try it out. It's not on crates.io yet since it isn't quite done, but it should be there Soon.

• Platform timer events (timeout,repeat) NSTimer, WM_TIMER and such. (atm mac only)
• Posting a user-event to the message queue from another thread (atm mac only)
• A 'block or not' bool on the event api, not have 2 different poll calls (see https://github.com/makepad/makepad/blob/master/render/src/cx_mtl.rs#L211(
• Window resize events on windows seem to be arriving much faster than i can draw causing a lag in the window resize

Those have actually all been addressed by the API rework! Check out the API docs for that specific module here: https://osspial.github.io/winit/el2-win-joy/winit/event_loop/index.html.

• Wasm32-unknown-unknown support

This is being worked on, but probably won't be ready for the initial eventloop-2.0 release. See #797.

• 1 out of 5 startups on mac my mouse down events didnt work at all (dont know why).
• IME support on mac just did nothing, half implemented it seemed

I'll admit that I don't know if these have been fixed, but it's worth checking out the eventloop-2.0 branch to see if either of those issues have been addressed. I'm willing to bet that the mouse issues will no longer happen.

• Web compatible clipboard support API that also works on (web/mac only atm)

This is out of scope for Winit, as it should be possible to implement externally.

• Same keyboard input method as web (so no virtual key translation please)

We explicitly aren't going to do this (see #753 (comment) and its thread for why, exactly), but we hear you that the keyboard input API currently isn't very good. That's on the docket to tackle.

---

Long story short, I totally get being frustrated with the state of this library right now - hell, I'm helping maintain it because it wasn't fitting my needs as a user. However, we're very much aware of the many issues it faces, and have been making progress towards addressing them!

[goddessfreya]

Closing since questions were answered.