Summary: | Using keyboard shortcut for Move Tool works but then immediately jumps to Shape Select (and shows "You probably want the Move Tool" message) | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | kother |
Component: | Shortcuts and Canvas Input Settings | Assignee: | Krita Bugs <krita-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | eoinoneill1991, halla, kother |
Priority: | NOR | Keywords: | investigated, triaged |
Version: | 4.1.0 | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
kother
2018-07-13 19:06:48 UTC
Bug confirmed! Application Version: Master 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. The 'V' key isn't hardcoded: it can be reset in the canvas input settings dialog. It's a issue known that the shortcut conflict checker doesn't also check the canvas input settings. *** This bug has been marked as a duplicate of bug 329663 *** |