Winit: DeviceIds contain no data on most platforms

[Xaeroxe]

This needs to be fixed: https://github.com/tomaka/winit/blob/master/src/platform/windows/mod.rs#L22

Since Windows makes up 96% of gamers at the moment this effectively makes the DeviceId useless.

EDIT: winit is not exclusively a gaming library.

[Xaeroxe]

Having just browsed the Windows source, I can now tell you this isn't as bad as it first appears because the only places this is used is in keyboard and mouse input, and thanks to the distinction between those events it's actually impossible to confuse these. So the DeviceId, while useless, also isn't really needed.

[Xaeroxe]

Just found this is also an issue for OSX.

[Xaeroxe]

After even further scouring this is literally only used for the X11 backend. DeviceId is just a dummy value for every other platform.

[Xaeroxe]

So, I'd like to propose that we restructure events. Since 99% of the time DeviceEvents are just raw mouse input we should label them as such, then create a new event for non-mouse devices that will only be emitted on X11 (and maybe other platforms if support for that is ever added)

Further, we should remove most of the DeviceIds from the current event structure, as they currently only serve to confuse people and basically just lie about the library's capabilities.

[Xaeroxe]

DeviceEvent::Added and DeviceEvent::Removed are completely dead. Never emitted anywhere.

[torkleyy]

Device ids can be useful when using multiseat AFAIK.

[Xaeroxe]

@torkleyy Sure, but that's only meaningful if the device id actually carries any data. It doesn't 99% of the time, throughout most of winit it's just dead characters.

[torkleyy]

So what is it that you're suggesting?

[Xaeroxe]

Key:

• M - Modify
• R - Remove
• A - Add

R DeviceEvent::Added

R DeviceEvent::Removed

R WindowEvent::AxisMotion

M WindowEvent Remove all DeviceIds from this enum, as they carry 0 useful data

M winit::Touch remove the DeviceId as it's also useless

M DeviceEvent::Button and DeviceEvent::Motion Either start emitting these for devices other than the mouse on platforms other than X11, or just remove it entirely. Having this behave as it does today is dangerous as it can lead developers to believe they have support for arbitrary input devices on all platforms when in fact they are far from it.

R DeviceEvent::Key - Not needed when the window isn't focused

R DeviceEvent::Text - Not needed when the window isn't focused

M WindowEvent::MouseMoved rename this to CursorMoved.

A WindowEvent::MouseMoved largely replaces today's DeviceEvent::Motion, but includes semantics for this being the mouse. Also includes both x and y, rather than just one axis.

[Ralith]

The proposed changes include significant regressions.

Having just browsed the Windows source, I can now tell you this isn't as bad as it first appears because the only places this is used is in keyboard and mouse input, and thanks to the distinction between those events it's actually impossible to confuse these. So the DeviceId, while useless, also isn't really needed.

The purpose of DeviceId is to distinguish between different keyboards and mice (for example), not to distinguish keyboards from mice.

DeviceEvent::Added and DeviceEvent::Removed are completely dead. Never emitted anywhere.

I'm not sure how you came to this conclusion. They are used on the X11 backend, and are necessary for good hotplugging support.

M DeviceEvent::Button and DeviceEvent::Motion Either start emitting these for devices other than the mouse on platforms other than X11, or just remove it entirely. Having this behave as it does today is dangerous as it can lead developers to believe they have support for arbitrary input devices on all platforms when in fact they are far from it.

These are expected to be necessary to access non-mouse/kb devices on Wayland; upstream plans preclude the normal, winit-independent linux input device methods.

A WindowEvent::MouseMoved largely replaces today's DeviceEvent::Motion, but includes semantics for this being the mouse. Also includes both x and y, rather than just one axis.

Physical mouse (as opposed to cursor) motion is not associated with a window on most platforms. This is why the DeviceEvent notion exists.

On the whole, your reasoning here seems to be "Windows support for these recently introduced features is lacking, therefore they should be removed entirely." If Windows support concerns you to that extent, I suggest completing it instead. If you are only concerned about confusion but are not actually interested in the features, documenting their completeness would probably be appropriate.

While Windows may account for "96% of gamers," winit is not only a game library, and I believe its users are not nearly so concentrated.

[Xaeroxe]

The purpose of DeviceId is to distinguish between different keyboards and mice (for example), not to distinguish keyboards from mice.

It fails entirely in this regard as for every platform that isn't X11 it's Eq implementation is literally just return true;

These are expected to be necessary to access non-mouse/kb devices on Wayland; upstream plans preclude the normal, winit-independent linux input device methods.

Great! But right now we have so many other places these could be used but they just aren't. Finish the job, don't do it at all, or indicate in documentation somehow this is very incomplete.

I'm going to call a straw man fallacy on the windows portion of your comment. This started as a Windows issue but the scope has changed to encompass literally everything that isn't X11. You on the other hand seem entirely concerned with the Linux experience and have paid no heed to the impact on other platforms.

[Ralith]

Finish the job, don't do it at all, or indicate in documentation somehow this is very incomplete.

winit is not a finished library. Refer to https://github.com/tomaka/winit/issues/252 for detailed discussion of platform support consistency. Contributions to improve and maintain documentation about this would certainly be valuable. Removing all incompletely supported features would not leave very much.

[Xaeroxe]

I'm not sure how you came to this conclusion. They are used on the X11 backend, and are necessary for good hotplugging support.

My bad. I missed their usage when I did my search.

Physical mouse (as opposed to cursor) motion is not associated with a window on most platforms. This is why the DeviceEvent notion exists.

I understand that. By the time I got done with my list the DeviceEvent enum was so sparse that it made more sense to just drop it and integrate the last remaining event into WindowEvent. If we keep DeviceEvent then it makes sense to keep it there.

[Ralith]

By the time I got done with my list the DeviceEvent enum was so sparse that it made more sense to just drop it and integrate the last remaining event into WindowEvent

WindowEvents must be associated with a window. Mouse movement may be received even if there are no windows, so this is not possible.

To be clear, I absolutely am concerned for the quality of winit's API across all major platforms. I cannot personally supply implementations for a given feature on every single platform, but I want to be sure we produce a rich and usable API that is useful and realistically implementable in most places. To my knowledge, based on discussions with @retep998, these features make perfect sense on Windows, and do not represent a disproportionate implementation challenge.

Some of the proposed changes seem reasonable to me. Wholesale removal of device IDs and events are not one of them, but e.g. the proposed renamings seem like a clarity boon.

[Xaeroxe]

A lot of my complaints are resolved by #344 .

Before we can close this issue we should

• Add support for arbitrary input devices on all platforms as best as we can
• Make the DeviceId useful based on those input devices.

[Ralith]

See also https://github.com/tomaka/winit/issues/212 for prior musing on arbitrary input device support.

[francesca64]

DeviceId is potentially useful on Windows now (#482).

[Xaeroxe]

Thanks @francesca64 !

[francesca64]

I should note that there doesn't seem to be any solution to this on macOS, and I'm also not optimistic about a solution for WindowEvent on Windows.

[Xaeroxe]

I'm content closing this then

On Sat, Jun 2, 2018, 21:03 Francesca Frangipane [e-mail]
wrote:

I should note that there doesn't seem to be any solution to this on macOS,
and I'm also not optimistic about a solution for WindowEvent on Windows.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tomaka/winit/issues/338#issuecomment-394131494, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AF5Uci_cMkCcqdq1V9-DbWgiUScM8LOcks5t41ISgaJpZM4QQa_Z
.