https://bugs.kde.org/show_bug.cgi?id=396487
--- Comment #2 from Eoin O'Neill <eoinoneill1...@gmail.com> --- So I've further investigated this issue and it turns out to be rather interesting. The issue is that the V key is treated as a special key in krita, much like the control key or R key or Y key. However, unlike those keys, the V key changes the state of the tool selection because it acts as a temporary shortcut to the line tool when over the canvas area. When you bind the V key to a tool, it creates an issue where it loses the pointer to the previously used tool and decides to go to the selection tool. The quick (ugly) solution is to prevent the V key from being bound to. Since the V key has some hard coded behavior (switching to the line tool), it should not be able to be rebound for the time being. The long-term (better) solution is to remove hard coded attributes, temporarily lose the quick-access to the line tool, and try to rely more on the hotkey manager to do these types of behaviors. The even longer-term (best) solution is to provide more flexibility to our hotkey / tool system to allow for both modal hotkeys (permanent switching to different tools) and a temporary 'stack' based tool switch, which allows you to hold a key to use a tool and switch back after release. -- You are receiving this mail because: You are watching all bug changes.
