rust-windowing / winit Goto Github PK

View Code? Open in Web Editor NEW

4.7K 4.7K 880.0 10.77 MB

Window handling library in pure Rust

Home Page: https://docs.rs/winit/

License: Apache License 2.0

Rust 99.96% JavaScript 0.03% TypeScript 0.01%

android gui ios macos rust rust-lang wasm wayland windowing windows x11

winit's People

Contributors

Stargazers

Watchers

Forkers

fkaa elinorbgr osspial nicokoch ozkriff emilgardis sklopi mitchmindtree wvdschel frewsxcv zerosign tanderegg rerion bpostlethwaite jrmuizel samdphillips nowl chances bvssvni azriel91 pedrocr paulrouget denialadams cactorium gui1117 jwilm uk992 syntheorem sotaroikeda y-fujii mystal mortimergoro skligys torkleyy ralith gregkatz boscop gridbugs determinant codeforks brendanzab burtonageo glowcoil rukai conorlpboyle willglynn alexheretic shockham tmiller monomadic umurgdk mcginty zakorgy ekicyou bogdad mrmekon nequissimus trishume alteous technici4n gilbertw1 tiby312 chyvonomys golddranks stuartnelson3 diggsey lain-dono francesca64 heh9 yonran bgourlie kvark mcoffin robertgzr jtitor spearman lolzballs b-r-u forbjok x0ddf larago sodiumjoe jturner314 jice-nospam iquiw thermalspan hcpl icefoxen yvt ebarnard fschutt edwin0cheng virome green-s simonsapin branan goertzenator chrisduerr tinaun anderspitman

winit's Issues

PRs that need to be merged into winit

PRs that were merged in glutin but not in winit:

Consider using DwmFlush with a transparent window

Original: rust-windowing/glutin#461

Add method to close window

You provided a possibility to create/show/hide/resize window:
pub fn hide(&self) { self.window.hide() }
But I sure that 'pub fn close' method is also can be provided.

get_hwnd returns `*mut libc::c_void` rather than `winapi::HWND`

Key presses report "virtual" key presses (including repetition), not physical key down events

Original: rust-windowing/glutin#558

Change the way you get a window

Original: rust-windowing/glutin#175

resizability & min/max dimensions

Original: rust-windowing/glutin#681

Fullscreen mode is not reverted in X11

Original: rust-windowing/glutin#661

Second field of Event::KeyboardInput(..) is undocumented

Original: rust-windowing/glutin#662

Also related to #34, except that this is more about documentation.

Associate received characters with key inputs

Original: rust-windowing/glutin#201

Update README

The README file is still the one from glutin.

Force Touch causes weird behavior

Original: rust-windowing/glutin#672

[Linux] Multiple monitors identified as a single one

Original: rust-windowing/glutin#678

set_cursor_position blocks infinitely on x11

Original: rust-windowing/glutin#478

Events are broken when opening multiple windows

Original: rust-windowing/glutin#727

Multiwindow example is broken on OS X

Original: rust-windowing/glutin#618

RFC: Switch to a futures-compatible API

Winit's and glutin's current API look like this:

impl Window {
    pub fn wait_events(&self) -> impl Iterator<Item = Event> { ... }
    pub fn poll_events(&self) -> impl Iterator<Item = Event> { ... }
}

I suggest that instead you'd have to register your window to what's called an events loop. Then, you'd call a method on the events loop to run it. Running the events loop would process events received by the operating system, and call a callback previously registered on the window.

This is essentially the same approach as the future-rs library, except that we're not using future-rs directly because it's not totally stable. I'd like to eventually publish winit 1.0 (in, like, the next nine months or so), and it's unlikely that future-rs publishes its 1.0 before winit.

Example usage with the new API (just to give an overview, the details are not important at the moment):

let events_loop = EventsLoop::new();
let window = WindowBuilder::new().with_title("hello").build(&events_loop).unwrap();
window.set_callback(|event| match event { ... });

loop {
    events_loop.run_once();     // calls the closure passed to set_callback earlier
}

I've always been a bit wary about callbacks because they are often too "magical", like you don't know which thread calls them and at what moment. But the fact that it's the run() method of the events loop that calls the callbacks means that it's a good design in my opinion.

This approach would have some benefits over the current system:

In the implementation we can decouple the Window object in Rust from the actual window. The actual window could be stored in the EventsLoop for example.
Right now on Windows winit spawns a background thread for events handling ; this could be removed.
We can force the EventsLoop to run on the main thread for OSX while still allowing the Window objects to be shared between threads. This has been a huge safety hole in glutin since the beginning.
The set_resize_callback function of MacOS would be gone.
The WindowProxy would be gone in favor of an "EventsLoopProxy".
We can later register other kinds of callbacks to the events loop, for example a callback when a monitoring is plugged in or removed that is not tied to particular window.
This design is also more appropriate for emscripten in glutin, as emscripten/javascript are based on callbacks and not on preemptive multitasking.

Transparent example segfaults on OS X

Original: rust-windowing/glutin#619

Setting Cursor Position Inaccurate

Original: rust-windowing/glutin#663

Example "multiwindow" does not close on OSX

Original: rust-windowing/glutin#544

Full Screen Focus Switch OSX

Original: rust-windowing/glutin#720

Resize events not working on OSX

Original: rust-windowing/glutin#445

Clarification in the docs on key codes

Original: rust-windowing/glutin#259

Relative mouse motion

Original: rust-windowing/glutin#774

Window example on wayland creates 0x0 pixels window

It looks like winit doesn't resize wayland window after start (resize_callback function have not been called).
I've checked glutin example on wayland and it works well. Then I checked the difference beetween api/wayland/window.rs in winit and glutin and found out that there is no resize calls in winit. For example: glutin and winit. It seems to me that there should be some code to resize surface, but I haven't find any API in wayland-client to do so.

generate only the PixelDelta event ?
generate only the LineDelta event ?
generate both ?
modify the MouseWheel event so that it may provide both values ?