Handle WM_POINTER* events in favor of WM_TOUCH

[dam4rus]

As WM_TOUCH have some well document problems, I think it would be more appropriate to handle the WM_POINTERDOWN, WM_POINTERUPDATE and WM_POINTERUP event family whenever possible. Even though these events are only sent by Windows 8.1 or higher, they are more robust, easier to set up (no need to call Un-/RegisterTouchWindow) and less error prone.

[dam4rus]

As a side note, I read your call for help and even though i'm totally new to open source contribution, I would gladly help when- and where-ever i can. I have a full-time job as C++/Windows desktop application developer, so i have some experience with WinAPI, and would gladly learn and help with X11 stuff.

[Osspial]

Hi, and thanks for bringing this up/volunteering! Sorry about the delay in a response.

I can't see any much in the way of downsides in adding this. I don't have easy access to a Windows touchscreen device, so would you be able to implement this? I'd give mentoring instructions, but given the nature of this bug report you seem to have a good handle on how to go about making this change.

[dam4rus]

No problem about the delay. I created a PR for this issue.

During testing I noticed that touch events' location are screen coordinates, not client coordinates like mouse events. This is the default behavior on Windows, but is this the desired behavior for winit too?

[Osspial]

Thanks! And, we should translate into client area coordinates. That'll be more consistent with the rest of the API, and expressing the event in screen coordinates isn't actually possible on all backends (Wayland being the main exception I'm aware of).

[dam4rus]

Sorry for the late answer! I've created a new issue for touch events emitting screen coordinates.