Change Details

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, we inject the mouse events into Qt directly, bypassing the OS. This mainly helps with Windows ver 1709 where touch events gets synthesized first instead of mouse input and causes weird behaviour. This also makes it act a bit more like the WInTab mode, except that WinTab produces the synthesized mouse events not from Qt. (See also: https://bugs.kde.org/show_bug.cgi?id=386476) However, this exposes several issues within Krita: 1. Certain places in Krita rely on `QCursor::pos()` to get the cursor position. `QCursor::pos()` calls `GetCursorPos` WinAPI. Since Windows doesn't update the cursor position if the non-mouse 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) 2. Since the mouse event is synthesized after the tablet event is sent, calling up the canvas popup palette would result in an unwanted click on the palette. 3. The advanced colour selector acts weirdly with pen clicks and drags.

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. Commit message: 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

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, we inject the mouse events into Qt directlyus (which doesn't work properly on ver 1709), bypassing the OS.we inject the mouse events into Windows for handled pen events, This mainly helps with Windows ver 1709 where touch events gets synthesized first instead of mouse input and causes weird behaviourand just let Windows synthesize touch+mouse events normally for unhandled pen events. This also makes it act a bit more like the WInTab mode, except that WinTab produces the synthesized mouse events not from Qt. (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. However, this exposes several issues within Krita:Commit message: 1. Certain places in Krita rely on `QCursor::pos()` to get the cursor position. `QCursor::pos()` calls `GetCursorPos` WinAPI. Since Windows doesn't update the cursor position if the non-mouse pointer events are handled, certain elements would fail to follow the pen. 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, (E.g. parallel ruler assistant: https://bugs.kde.org/show_bug.cgi?id=so that the cursor position is updated to get correct results from QCursor::pos(). BUG: 386475) 2. Since the mouse event is synthesized after the tablet event is sent, calling up the canvas popup palette would result in an unwanted click on the palette. BUG: 386476 3. The advanced colour selector acts weirdly with pen clicks and drags. Differential Revision: https://phabricator.kde.org/D8801