| Summary: | Two finger drag "zoom and rotate" and one finger drag "pan canvas" does not continue seamlessly | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Alvin Wong <alvin> |
| Component: | Shortcuts and Canvas Input Settings | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | griffinvalley, shzam |
| 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
2022-06-14 11:16:41 UTC
I am marking this as a regression because this had been working with the old touch gesture implementation in 5.0 (when touch painting is disabled). Hello! Well, this is something that I did intentionally. Let's say if we assign "One Finger Drag" to "Alternate Invocation (Sample Foreground Color from Merged Image)", then once the user lifts the finger (say in 2 finger drag) this alternate invocation would start immediately and can be annoying. Yes, we can add some slop before we start this action, but I thought disabling it altogether would be more preferable? Well, but I do not have colour sampler assigned to one finger drag. My point is that the combination of "pan canvas" and "zoom and rotate canvas" gestures is special in that it should turn the canvas into a direct manipulation surface. Switching between these two gestures should be seamless as any touchscreen users would expect, and like other applications out there. For any other gestures, yes, not switching would be the logical choice. Given sh_zam can reproduce this, I'll mark it as confirmed. |