| Summary: | Parallel ruler doesn't follow cursor when drawing with Pointer Input API | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Alvin Wong <alvin> |
| Component: | Tablets (tablet issues are only very rarely bugs in Krita!) | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | halla |
| Priority: | NOR | ||
| Version: | git master (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://commits.kde.org/krita/2ae618848b4fd9ca76bc71abd41a9f41fb328d5e | Version Fixed In: | |
| Attachments: | tablet log | ||
|
Description
Alvin Wong
2017-11-02 18:53:52 UTC
I might be missing something, but this does seem to work for me. * I enabled cursor and brush outline * Create a parallel ruler assistant * Enabled magnetism * Moved the pen without touching: the cursor moved along * Painted a line: the cursor moved along. Oh, this is with 1703, on my SP3 and windows 8 pointer api enabled. Created attachment 108747 [details]
tablet log
It seems that no mouse move events get sent when the pen is drawing.
My implementation of the pointer input api lets Windows generate the mouse move events by "ignoring" all the pen move events (while accepting the pen down/up events), which seems to work on 1703 but is now broken on 1709. I guess it might be a side-effect of Windows being changed to synthesize touch events first on pen down.
The question is, are the assistants updated only on mouse move but not tablet move? I think it's not a really good idea to rely on mouse events always being synthesized. (But then Qt does have its mouse event synthesizing code which can be enabled/disabled if the OS does not synthesize mouse events itself... which can't be used from my home-grown pointer input code...)
If Krita really does always expect mouse events, I can potentially add mouse event synthesizing code, but it can get messy :/
Looks like it's due to the assistants relying on `QCursor::pos()`, which gets the cursor position directly from Windows and isn't updated due to the way Windows handles the events. Actually, I suspect it might even not work on Linux if mouse events are synthesized from tablet events by Qt... Git commit b0dbfeb13c368ce262a2e959fd1ffa0bca32f099 by Alvin Wong. Committed on 12/12/2017 at 15:56. Pushed by alvinwong into branch 'master'. 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(). Related: bug 386476 Differential Revision: https://phabricator.kde.org/D8801 M +102 -15 libs/ui/input/wintab/kis_tablet_support_win8.cpp https://commits.kde.org/krita/b0dbfeb13c368ce262a2e959fd1ffa0bca32f099 Git commit 2ae618848b4fd9ca76bc71abd41a9f41fb328d5e by Alvin Wong. Committed on 12/12/2017 at 16:04. Pushed by alvinwong into branch 'krita/3.3'. 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(). Related: bug 386476 Differential Revision: https://phabricator.kde.org/D8801 (cherry picked from commit b0dbfeb13c368ce262a2e959fd1ffa0bca32f099) M +102 -15 libs/ui/input/wintab/kis_tablet_support_win8.cpp https://commits.kde.org/krita/2ae618848b4fd9ca76bc71abd41a9f41fb328d5e |