Bug 442342 - Cursor brush outline not visible on first pen proximity after opening document
Summary: Cursor brush outline not visible on first pen proximity after opening document
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Usability (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-09-12 15:35 UTC by Alvin Wong
Modified: 2022-01-08 12:38 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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