This changes the behaviour of the WIndows Pointer Input handling code. Instead of "ignoring" the pointer events and hoping that Windows will synthesize mouse events for us (which doesn't work properly on ver 1709), we inject the mouse events into Windows for handled pen events, and just let Windows synthesize touch+mouse events normally for unhandled pen events.
This also makes it act more like the WInTab mode.
(See also: https://bugs.kde.org/show_bug.cgi?id=386476)
This mainly fixes code that rely on QCursor::pos() to get the cursor position. QCursor::pos() calls GetCursorPos WinAPI. Since Windows doesn't update the cursor position if the pen pointer events are handled, certain elements would fail to follow the pen. (E.g. parallel ruler assistant: https://bugs.kde.org/show_bug.cgi?id=386475)
There is an issue where calling up the canvas popup palette would result in an unwanted click on the palette, but it also happens with WinTab so it's not new. It's a side-effect of mouse events being sent after the tablet events.
It is a hackish solution, but there is no way I can change QCursor::pos() to also use the pen position.
WinInk: Simulate native mouse events for handled pen events The code now simulates native mouse events with `SetCursorPos` and `SendInput` for pen pointer events whose QTabletEvents are handled by the widgets, so that the cursor position is updated to get correct results from QCursor::pos(). BUG: 386475 BUG: 386476 Differential Revision: https://phabricator.kde.org/D8801