Bug 442342

Summary: Cursor brush outline not visible on first pen proximity after opening document
Product: [Applications] krita Reporter: Alvin Wong <alvin>
Component: UsabilityAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED FIXED    
Severity: normal CC: dimula73, spikestheraccon, tomtomtomreportingin
Priority: NOR Keywords: regression
Version First Reported In: nightly build (please specify the git hash!)   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Alvin Wong 2021-09-12 15:35:03 UTC
STEPS TO REPRODUCE
1. Open document
2. After document is opened, bring stylus within tablet proximity
3. Observe cursor brush outline

OBSERVED RESULT

Cursor brush outline not visible.

EXPECTED RESULT

Cursor brush outline should be visible.

SOFTWARE/OS VERSIONS
Windows: 10
Commit: 2876937

ADDITIONAL INFORMATION

Happens on Surface Pro gen 5 with both Windows Ink and WinTab
Comment 1 tomtomtomreportingin 2021-11-30 08:34:18 UTC
I can confirm this, however, on my end with a stock Wacom Intuos stylus on Debian sid, it only occurs when opening a document AND when using a mouse.

In 4.4.7, when opening a recent document with a mouse, the system cursor is still visible, the drawing cursor isn't visible, but the preview is visible.
In beta 1, beta 2, and 5.0 git e650032, neither the preview nor drawing cursor is visible, only showing the system cursor.  Therefore, this is some regressive behavior here.

Ideally it should immediately show the proper cursors/previews in every case.
Comment 2 Dmitry Kazakov 2021-12-24 07:13:28 UTC
People report that the same problem happens when one flips Pen/Eraser ends of the stylus.
Comment 3 Dmitry Kazakov 2022-01-08 10:42:00 UTC
I can confirm both problems. The first time the stylus tip enters the document directly (without hovering the GUI elements), the outline is not visible. If one flips the stylus the same problem happens for the second stylus tip.
Comment 4 Dmitry Kazakov 2022-01-08 12:35:38 UTC
Git commit d9fd398bfc2ab156bf25c7f629d470f920f081c8 by Dmitry Kazakov.
Committed on 08/01/2022 at 12:35.
Pushed by dkazakov into branch 'master'.

Fix brush outline when the tool is switched by the new stylus proximity

Normally, when we switch tool we switch it either by a button press
or a mouse click. Both these actions call prepareReadyShortcuts()+
tryActivateReadyShortcut() as a normal routine. But when a new tool
is activated implicitly by presenting a new stylus to Krita, there was
no activation, so the tool's primary action was not activated and,
therefore, there was no outline.

M  +2    -0    libs/ui/input/kis_input_manager.cpp
M  +16   -0    libs/ui/input/kis_shortcut_matcher.cpp
M  +6    -0    libs/ui/input/kis_shortcut_matcher.h

https://invent.kde.org/graphics/krita/commit/d9fd398bfc2ab156bf25c7f629d470f920f081c8
Comment 5 Dmitry Kazakov 2022-01-08 12:38:39 UTC
Git commit 79665213f2775b24d2c5c46b889a8d14e1be2ef9 by Dmitry Kazakov.
Committed on 08/01/2022 at 12:35.
Pushed by dkazakov into branch 'krita/5.0'.

Fix brush outline when the tool is switched by the new stylus proximity

Normally, when we switch tool we switch it either by a button press
or a mouse click. Both these actions call prepareReadyShortcuts()+
tryActivateReadyShortcut() as a normal routine. But when a new tool
is activated implicitly by presenting a new stylus to Krita, there was
no activation, so the tool's primary action was not activated and,
therefore, there was no outline.
(cherry picked from commit d9fd398bfc2ab156bf25c7f629d470f920f081c8)

M  +2    -0    libs/ui/input/kis_input_manager.cpp
M  +16   -0    libs/ui/input/kis_shortcut_matcher.cpp
M  +6    -0    libs/ui/input/kis_shortcut_matcher.h

https://invent.kde.org/graphics/krita/commit/79665213f2775b24d2c5c46b889a8d14e1be2ef9