| Summary: | Unable to pan after picking color from reference image until canvas is clicked once first | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Andy Statia <astatia> |
| Component: | Tools | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dimula73, halla, MartijnJoosstens, peat, putz.alexey, stefano_urru, xb_creations |
| Priority: | NOR | ||
| Version: | 3.1 Beta | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/483d38ba26d4008a74c16f5f96c525ff997b618c | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Andy Statia
2016-11-18 21:00:13 UTC
This issue also appears to affect the colour picker (and probably any tool change prompted by a keyboard shortcut). Hello. I tried it and I didn't reproduce the bug. I used Krita from page : https://krita.org/en/item/krita-3-1-beta-4-released/ Krita version 3.0.93 1. Opened an image. 2. Used the pick color tool, color was successfully picked. 3. Used pan shortcut (space), the icon of colorpicker was successfully changed to the icon of pan (hand). 4. Navigated with pan without need to click before pan. 5. Used ctrl+r shortcut, the icon changed successfully, selected a rectangular area. 6. Used Pan with shortcut space. Kubuntu 16.10 KDE Plasma Version : 5.7.5 KDE Frameworks Version : 5.26.0 Qt Version : 5.6.1 Kernel Version : 4.8.0-22-generic OS Type: 64-bit In your replication steps, I don't see where you opened a reference image to choose a colour from. If I do the steps as noted by you, it also works for me. The issue only arises if you pick a colour from the image in the reference image panel, not from the current document. (In reply to Alexey Putz from comment #2) > Hello. > I tried it and I didn't reproduce the bug. > I used Krita from page : > > https://krita.org/en/item/krita-3-1-beta-4-released/ > > Krita version 3.0.93 > > 1. Opened an image. > 2. Used the pick color tool, color was successfully picked. > 3. Used pan shortcut (space), the icon of colorpicker was successfully > changed to the icon of pan (hand). > 4. Navigated with pan without need to click before pan. > 5. Used ctrl+r shortcut, the icon changed successfully, selected a > rectangular area. > 6. Used Pan with shortcut space. > > > Kubuntu 16.10 > KDE Plasma Version : 5.7.5 > KDE Frameworks Version : 5.26.0 > Qt Version : 5.6.1 > Kernel Version : 4.8.0-22-generic > OS Type: 64-bit Thanks for your comment, I was able to reproduce this bug. 1. Open the reference image toolbar.(Settings - Dockers - Reference images) 2. Open an image at the toolbar. 3. Open an image in primary document window. 4. Use color picking tool at the reference image. 5. Quickly slide the cursor back on the primary document window image. 6. Bag occurs. While pressing hotkey for Pan the pan mode is not activated, the cursor stays in the color picking mode representation. Note: If cursor slided very smooth over the bound between the reference image area and main document window the bug doesn't occur. Krita version 3.0.93 Kubuntu 16.10 KDE Plasma Version : 5.7.5 KDE Frameworks Version : 5.26.0 Qt Version : 5.6.1 Kernel Version : 4.8.0-22-generic OS Type: 64-bit Awesome! I recorded a video of the replication as well in case it is useful. https://www.youtube.com/watch?v=pfk94vmyrK8 This issue seems to be much broader than just the reference docker. Clicking on almost any UI element (tool buttons, layer docker items, etc.) prevents certain tool switching until you click the canvas once. Tested by choosing different tools from the toolbar and trying to use pan, clicking a layer (Layers panel), or any setting in a panel. *** Bug 373299 has been marked as a duplicate of this bug. *** Hi, Andy and Alexey! As far as I can see, only cursor icon doesn't change when you move out of the docker. If you press space and start a drag (even thought the cursor is wrong) the panning action will start correctly. Could you check if you can start panning correctly? If so, the report is still a bug, yes, but not a release blocker at least. And I will check what can be done there to update the icon correctly. As far as I remember, we wait for 1 or 2 seconds of hovering over the canvas and then start pre-activation of actions, which involve updating the cursor. When doing this, I always end up drawing a line across my canvas instead of panning, which I have to undo quickly and then re-try the pan (which would then work since the canvas had been clicked). So unfortunately, it's not just a matter of the cursor not updating. I'm not sure I'd even have noticed it if that were the case. As it is, I'm very frequently having to undo that stroke across my work received when trying to pan. What I'm observing is that clicking in certain dockers and then hovering over the canvas and not moving makes things like pan and zoom unavailable. I can wait as long as I want and press the spacebar all I want, it doesn't react. But if I do the same thing and instead of keeping my cursor still I wiggle it around for a second, then pan and zoom do work. So that 1-2 second wait Dmitry mentions might be related? Hm, the original report was about the reference docker, and that's removed now, so I wonder whether we couldn't just close this bug. Why not rename it? The bug is still there, it's just broader then originally perceived. Git commit 5438445da9651785585ea913c37293737a5ee608 by Boudewijn Rempt. Committed on 10/04/2020 at 08:59. Pushed by rempt into branch 'master'. Set focus on the view on mouse-over This "should" solve the issues we have when an widget in a docker has input focus, and people move the cursor back to the canvas and start to pan or paint. However, it's a _very_ brute-force method, so we all need to be aware of this change and check whether stupid things happen, in which case we might need to do something a bit more subtle, with timers or so... CCMAIL:kimageshop@kde.org M +6 -0 libs/ui/KisView.cpp M +1 -0 libs/ui/KisView.h https://invent.kde.org/kde/krita/commit/5438445da9651785585ea913c37293737a5ee608 *** Bug 391088 has been marked as a duplicate of this bug. *** Git commit d454a04e713c0ffc4167021680f69be3698871ec by Dmitry Kazakov. Committed on 15/04/2020 at 20:46. Pushed by dkazakov into branch 'krita/4.3'. Fix pan/zoom shortcuts not working after accessing any docker The reason for the bug was that KisExtendedModifiersMapper:: queryExtendedModifiers() has never been implemented for Windows. Therefore all the shortcuts including Space could potentially be lost when the user pressed it without focusing on the canvas. We also need an implementation for OSX. Related: bug 373299, bug 391088 M +53 -3 libs/ui/input/kis_extended_modifiers_mapper.cpp https://invent.kde.org/kde/krita/commit/d454a04e713c0ffc4167021680f69be3698871ec Git commit f49dac3a603d8d40108523be436be1b251966ac5 by Dmitry Kazakov. Committed on 15/04/2020 at 20:48. Pushed by dkazakov into branch 'master'. Fix pan/zoom shortcuts not working after accessing any docker The reason for the bug was that KisExtendedModifiersMapper:: queryExtendedModifiers() has never been implemented for Windows. Therefore all the shortcuts including Space could potentially be lost when the user pressed it without focusing on the canvas. We also need an implementation for OSX. Related: bug 373299, bug 391088 M +53 -3 libs/ui/input/kis_extended_modifiers_mapper.cpp https://invent.kde.org/kde/krita/commit/f49dac3a603d8d40108523be436be1b251966ac5 Git commit 4b9fa0c85e8f4cf9412ad01dd073c4a83ac7ea67 by Ivan Yossi. Committed on 19/05/2020 at 06:04. Pushed by ivany into branch 'master'. fix extenderModifiers for OSX Keys other than modifiers cannot be accessed outside of non key related events from NSApplication. adding a local monitor allows to catch the keys we need during the delay duration. Try to handle all modifiers from localMonitor Apply modifiers already pressed on focusIn events macos We now request a copy of keydown and modifier change events to set the proper flags as background application Related: bug 373299, bug 391088 M +1 -0 libs/ui/CMakeLists.txt M +18 -0 libs/ui/input/kis_extended_modifiers_mapper.cpp M +5 -0 libs/ui/input/kis_extended_modifiers_mapper.h C +14 -26 libs/ui/input/kis_extended_modifiers_mapper_osx.h [from: libs/ui/input/kis_extended_modifiers_mapper.h - 051% similarity] A +134 -0 libs/ui/input/kis_extended_modifiers_mapper_osx.mm M +6 -0 libs/ui/input/kis_input_manager.cpp M +12 -0 libs/ui/input/kis_input_manager_p.cpp https://invent.kde.org/graphics/krita/commit/4b9fa0c85e8f4cf9412ad01dd073c4a83ac7ea67 Git commit 483d38ba26d4008a74c16f5f96c525ff997b618c by Boudewijn Rempt, on behalf of Ivan Yossi. Committed on 19/05/2020 at 09:08. Pushed by rempt into branch 'krita/4.3'. fix extenderModifiers for OSX Keys other than modifiers cannot be accessed outside of non key related events from NSApplication. adding a local monitor allows to catch the keys we need during the delay duration. Try to handle all modifiers from localMonitor Apply modifiers already pressed on focusIn events macos We now request a copy of keydown and modifier change events to set the proper flags as background application Related: bug 373299, bug 391088 (cherry picked from commit 4b9fa0c85e8f4cf9412ad01dd073c4a83ac7ea67) M +1 -0 libs/ui/CMakeLists.txt M +18 -0 libs/ui/input/kis_extended_modifiers_mapper.cpp M +5 -0 libs/ui/input/kis_extended_modifiers_mapper.h C +14 -26 libs/ui/input/kis_extended_modifiers_mapper_osx.h [from: libs/ui/input/kis_extended_modifiers_mapper.h - 051% similarity] A +134 -0 libs/ui/input/kis_extended_modifiers_mapper_osx.mm M +6 -0 libs/ui/input/kis_input_manager.cpp M +12 -0 libs/ui/input/kis_input_manager_p.cpp https://invent.kde.org/graphics/krita/commit/483d38ba26d4008a74c16f5f96c525ff997b618c |