-
Notifications
You must be signed in to change notification settings - Fork 885
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Device Events API Discussion #750
Comments
What's the device event API's purpose? A typical application should only be interested in events that happens when it's focused. Apart from that, DeviceEvent as it stands is mostly useless because backend implementations are mostly incomplete. |
It's got a couple purposes:
I don't get what you're going for there? |
I think I got confused because the TBH I think these thing have nothing to do with window focus (except gamepad); do we really receive those mouse events when the mouse is outside the window? This seems to be another confusing factor that makes the documentation harder to understand at a glance. |
Is this something which could be actually handled independently of |
@ishitatsuyuki Ah, that makes sense. FWIW, keyboard device input is implemented on the
@msiglreith From what I've seen, no. On Windows, device events are delivered as standard events in the platform event queue, and I'd assume that's the case on other platforms. Design-wise, why would we want it in a separate crate? It seems fairly natural for us to expose this, given the high-level goals of this crate. |
@Osspial On windows, one can just create a new hidden window and poll from there 😛
I'm not sure what's supposed to be the scope of winit, IIRC gamepad support for example was always treated as it should be supported by a separate crate. Pros: Keep the scope of |
We pretty much do that already, actually. The role of that window has been expanded to handle device events on the
We expanded our scope to include that a bit ago, though I can understand the confusion there since Tomaka was pretty insistent that it didn't belong in Winit. See https://github.com/rust-windowing/winit/blob/master/FEATURES.md |
This is completely against intuition, as that's not GUI input is typically exposed. The reason I get confused with this is due to the fact that you spawn a hidden window - I can't predict such implementation from the docs, and therefore I would just think receiving events without focus is not possible. After all, capturing inputs globally is a kind of keylogging - am I correct? |
That's true, but device events don't behave the same way as traditional GUI input. The OS creates window events by aggregating together events from multiple devices and filtering the device input (mouse movement and acceleration being the most notable examples of this), but the device events themselves can still be retrieved and processed without that filtering. Said events aren't associated with a window, because the OS hasn't associated them with a window - instead, they're associated with the device that produced them.
I think I phrased my previous comment poorly - we don't actually do that right now on master. The |
We have recently discussed on Matrix to remove Unless some useful use-case is presented, we plan to move ahead with it. We have already decided that we don't plan to cover Gamepads in Winit and only plan to expose UUIDs for external crates to be able to do all the work. Cc @notgull because this is basically a X11 issue only. EDIT: thanks @kchibisov, there is no |
I think we've discussed |
The Device Events API currently exists, but there seems to be informal consensus between the maintainers that it needs to be reworked somewhat before we can declare it stable. This issue is meant to house discussion on what changes should be made.
The text was updated successfully, but these errors were encountered: