Skip to content
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

Windows: Implement DeviceEvents #482

Merged
merged 2 commits into from
Apr 28, 2018

Conversation

francesca64
Copy link
Member

Fixes #467

All variants other than Text have been implemented. While Text can be implemented using ToUnicode, that doesn't play nice with dead keys, IME, etc.

Most of the mouse DeviceEvents were already implemented, but due to the flags that were used when registering for raw input events, they only worked when the window was in the foreground.

This is also a step forward for #338, as DeviceIds are no longer useless on Windows. On DeviceEvents, the DeviceId contains that device's handle. While that handle could ostensibly be used by developers to query device information, my actual reason for choosing it is because it's simply a very easy way to handle this. As a fun bonus, this enabled me to create this method:

DevideIdExt::get_persistent_identifier() -> Option<String>

Using this gives you a unique identifier for the device that persists across replugs/reboots/etc., so it's ideal for something like device-specific configuration.

There's a notable caveat to the new DeviceIds, which is that the value will always be 0 for a WindowEvent. There doesn't seem to be any straightforward way around this limitation.

I was concerned that multi-window applications would receive n copies of every DeviceEvent, but Windows only sends them to one window per application.

Lastly, there's a chance that these additions will cause antivirus/etc. software to detect winit applications as keyloggers. I don't know how likely that is to actually happen to people, but if it does become an issue, the raw input code is neatly sequestered and would be easy to make optional during compilation.

Fixes rust-windowing#467

All variants other than Text have been implemented. While Text can
be implemented using ToUnicode, that doesn't play nice with dead
keys, IME, etc.

Most of the mouse DeviceEvents were already implemented, but due
to the flags that were used when registering for raw input events,
they only worked when the window was in the foreground.

This is also a step forward for rust-windowing#338, as DeviceIds are no longer
useless on Windows. On DeviceEvents, the DeviceId contains that
device's handle. While that handle could ostensibly be used by
developers to query device information, my actual reason for
choosing it is because it's simply a very easy way to handle this.
As a fun bonus, this enabled me to create this method:
  DevideIdExt::get_persistent_identifier() -> Option<String>
Using this gives you a unique identifier for the device that
persists across replugs/reboots/etc., so it's ideal for something
like device-specific configuration.

There's a notable caveat to the new DeviceIds, which is that the
value will always be 0 for a WindowEvent. There doesn't seem to be
any straightforward way around this limitation.

I was concerned that multi-window applications would receive n
copies of every DeviceEvent, but Windows only sends them to one
window per application.

Lastly, there's a chance that these additions will cause
antivirus/etc. software to detect winit applications as keyloggers.
I don't know how likely that is to actually happen to people, but
if it does become an issue, the raw input code is neatly
sequestered and would be easy to make optional during compilation.
@francesca64
Copy link
Member Author

(I need to make sure I remember to re-export DeviceIdExt from glutin)

@francesca64 francesca64 merged commit fe2d37f into rust-windowing:master Apr 28, 2018
@Ralith
Copy link
Contributor

Ralith commented Apr 28, 2018

get_persistent_identifier

This can be implemented on Linux using udev_device_get_sysattr_value with "idVendor", "idProduct", and "serial", on the device node obtained by XIGetProperty on the "Device Node" atom. Would be pretty sweet to have as a portable API.

@francesca64
Copy link
Member Author

@Ralith thanks for the info. That sounds like a fun thing to implement, so I'll add it to my to-do list.

tmfink pushed a commit to tmfink/winit that referenced this pull request Jan 5, 2022
…ale-coords-fix

Scale offset in source image's own coordinate space
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants