I've been plagued with this issue for as long as I've used Krita, and it is a massive pain. Happens dozens, if not hundreds of times per art session. I'm hoping it's something that can be looked into or fixed, if not mitigated in some way, I can't imagine it's intentional. I draw very quickly and this breaks every point of my workflow and makes me waste time undoing what happens. Summary: When I interact with a docker other than the canvas, I have to tap the canvas 'out of bounds' before doing anything other than what I was previously doing. For instance, this will be my workflow, happening in under 2 seconds or so: The set up: I press b to select a brush. I draw a line I select a new layer on the layers docker. I hold [key] to do a quick zoom/quick rotate/any other quick action I drag my pen down on the canvas to zoom out What happens: I draw a line across my canvas What I expect to happen: I zoom out/rotate/whatever else because I'm holding the shortcut for it. Sometimes I don't even realize I accidentally drew a line, and have to spend time at the end of the piece going through each layer looking for stray lines I drew, or breaks in lines I erased. Krita Version: 4.3.0-prealpha (git 6310d2d) Qt Version (compiled): 5.12.5 Version (loaded): 5.12.5 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.17134 Pretty Productname: Windows 10 (10.0)
Hi Aaron, If that happens, it wouldn't be intentational, of course. I haven't exerienced what you describe myself. Would it be possible to make a screen recording, preferably one of those with keypresses showing automatically to show what's happening?
Created attachment 123432 [details] Example (In reply to Boudewijn Rempt from comment #1) Gladly, notice that after selecting the new layer, despite holding the 'move' button (space in this case) it still draws a line.
Settign to confirmed. this happens apparently because the canvas looses focus making the shortcut "captured" by the last window/docker. We probably should force focus on "enter"
After a short consultation with dmitry this actually is intended: There is a delya implemented to allow for better discrimation of shortcut events from canvas vs dockers. Fixing this is not trivial.
Regardless if it's trivial or not, it's causing multiple other problems for me. For instance my recent bug report https://bugs.kde.org/show_bug.cgi?id=425087 was later found to be caused by this way of handling shortcuts. After getting fed up with not being able to reproduce the issue, I decided to constantly record my screen and inputs until it happened again. Sure enough it did, and upon reviewing the footage, I found that my 'zoom' keyboard shortcut, set to `G`, was switching my current active layer to "Group". Why this is a major problem: Let's say I want to switch layers, and then zoom into the canvas. Simple right? How it should work: - I click the layer. - I hold my drag-zoom shortcut - I drag my pen on the canvas to zoom How I currently have to do it to workaround this issue: - I click the layer - I click the canvas to make it focus, which draws a dot - I press my eraser toggle shortcut to switch to eraser - I erase the dot I was just forced to make [Alternatively I can hit undo] - I hold my drag-zoom shortcut - I drag my pen on the canvas to zoom Solution: Either make clicking on the canvas docker /only/ focus it, or make it automatically focus on hover ("Focus" being, disable all other docker-specific shortcuts like "G" selecting a group layer in the layers docker). Anything else is extremely annoying.
> Either make clicking on the canvas docker /only/ focus it That would be neat - if there was some check "if the canvas is not focused, just focus without painting/interacting". > make it automatically focus on hover It does, there is just a small delay for that. Maybe the delay should be even smaller, then. You can test it out by first doing the buggy behaviour (triggering the docker shortcut or not triggering a canvas one), and then doing the same thing but first waiting for a while with a pen over the canvas.
(In reply to vanyossi from comment #4) > After a short consultation with dmitry this actually is intended: There is a > delya implemented to allow for better discrimation of shortcut events from > canvas vs dockers. > > Fixing this is not trivial. If fixing is difficult because it was an intentional delay, can there be a way to allow the user to set this delay themselves if the delay is impeding their workflow?
I'm not sure exactly how this got fixed, but quickly moving from dockers to zooming/rotating the canvas no longer captures the shortcut and draws lines instead. Closing this as fixed.