https://bugs.kde.org/show_bug.cgi?id=390642
Ahmad <xwiza...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xwiza...@gmail.com
--- Comment #34 from Ahmad <xwiza...@gmail.com> ---
I've been doing some rudimentary debugging with info logs on MacOS. What I'm
noticing is that with just the mouse or touch events on the Wacom tablet, when
you move the cursor in and out of the canvas area it fires the QEvent::Enter
and QEvent::Leave events correctly.
However, with the Wacom Pen it gets tricky. When you first hover the pen on the
canvas it does QEvent::TabletEnterProximity. Now when you move the pen, while
still hovering, out of the canvas area onto one of the widgets, it triggers the
QEvent::Leave. However, now when you move the cursor back into the Canvas area,
it will not trigger QEvent::Enter anymore. During this time it picks the last
cursor shape change that occurs around the boundary of widgets. If you bring
the pen down to draw, nothing gets drawn. Also, QEvent::TabletMove continues to
fire regardless of whether the cursor is within bounds of any of the widgets in
the UI.
While its messed up, if you move the pen far enough off the tablet
QEvent::TabletEnterProximity gets triggered and when you move the pen back down
it will trigger QEvent::Enter correctly which resets the tool cursor and
followed by the QEvent::TabletEnterProximity. You can now draw normally until
you move the pen out of canvas bounds again.
I'm still trying to follow what the code is doing as I haven't touched C++ in
over a decade and not familiar with Qt and Krita. I'm wondering if there is
some weird edge case in the application logic where the cursor/tool icons are
shown/hidden and they need to take the status of the Wacom Pen being
hovered/not.
--
You are receiving this mail because:
You are watching all bug changes.
