SUMMARY When using canvas inputs on the canvas shortly after using UI elements (such as clicking a preset from the Brush Presets docker or closing the brush settings popup), these inputs will often clash with the UI elements, making the user unintentionally perform certain functions. STEPS TO REPRODUCE 1. Click a brush in the Brush Presets docker. 2. Move cursor over the canvas and press Tab swiftly after, attempting to enter Canvas-Only Mode. Observed result: The next brush preset in the docker is selected instead. Another example: 1. Open brush settings popup. 2. Close brush settings popup. 3. Move cursor over the canvas and press Space swiftly after, attempting to pan the canvas. Observed result: The brush settings popup pops up again. EXPECTED RESULT Focus should immediately switch to the canvas. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian sid KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.12.9 (Appimage) ADDITIONAL INFORMATION This quickly becomes annoying as it occurs more and more once the user becomes more "in tune" with their current project and session.
Another case where this is particularly annoying is attempting to pan the canvas with Spacebar right after selecting a new blending mode, in which instead of panning the canvas, the blending mode dropdown will pop up.
Another case: Change opacity of a layer, then immediately attempt to rotate the canvas with a canvas input bound to a number. This will result in both the canvas rotating AND digits being added to the opacity value.
Can confirm on win 10. Another example is layer docker - I select layer, press some key and different layer get selected. Weirdest part is that in docker it looks like correct layer still active (blue) while layer that actually will be changed seems like inactive except bold name.
*** Bug 457945 has been marked as a duplicate of this bug. ***
I reported this before as occurring after switching colour sampler to the "alt" key. After trying out different combinations, it seems that binding the colour sampler to "space" works fine, just like it would if it were bound to the default "ctrl". So for some reason it's different depending on what keys are pressed.
Yes, alt is special on Linux and Windows.
Yes, there is weird hack with transferring the focus from GUI elements to the canvas. I'm not sure how we can solve that gracefully... The problem is, in general, we cannot distinguish, whether the user pressed "Arrow Down" to change blendmode combo box (which is currently in focus) or to pan the canvas. We use a weird hack for that: when the mouse hovers the GUI elements, then GUI elements keep their input focus. When the mouse starts hovering the canvas, Krita waits for a short period of time and then transfers the focus to the canvas. The length of the delay depends on the type of the control the focus belonged to. For normal controls the delay is 400ms. For input boxes that allow actual typing the delay is 2000ms. If we remove the delay completely, then typing any values, like layer name or opacity will be really cumbersome. You will have to ensure that the stylus leaves the proximity on the GUI elements, not on the canvas. I don't know how to make this system better. If you have any solution, please tell :)
Well, let's consider realistic scenarios. In the case of dropdowns/popup buttons: The user isn't likely to set arrow keys to a canvas input. By default there is a canvas input using space. When does a user in practice ever want to open the blending mode dropdown using space? If such a workflow is very rare or does not exist, then if possible, dropdowns should ignore the space key. In the case of item selection widgets like the brush presets docker: Do users realistically change brush presets by using arrow keys or pressing numbers? If not, then maybe such item selection widgets should ignore arrow keys and numbers. In the layer docker case that radian mentioned: I've only noticed this very recently occuring when you select a layer and then press certain keys that correspond to another layer name. For example, selecting a layer and then pressing "j" will swap between layers that start with "j". It might be an undiscoverable, obscure feature that could be removed. In the case of the sliders: This one is tricky. I haven't really noticed before that you can just type into sliders simply by clicking and then typing. There could maybe be a different way to activate input on sliders. A probably radical solution would be to replace the canvas-facing spinbox sliders with qslider + spinbox combos which wouldn't be impacted much by focus issues.
A better idea regarding sliders: Perhaps the current slider spinbox widgets could have a developer-facing option to have an explicit spinbox on the side of the widget, so that focus isn't stolen when the user just wants to use the slider component. With such an option, focus would only be kept while keyboard input is enabled on the explicit spinbox. This would then be applied to the canvas-facing sliders. Might require artist discussion. This is a tangent mostly unrelated to the bug report itself, but I can't say I'm a fan of the merging of the slider and spinbox components of the slider spinboxes widgets. Not only does merging these components together cause the focus issues as described in this bug report, but I would say the current methods to enable keyboard input on sliders are undiscoverable and awkward. Holdclicking is not only undiscoverable, but in my case, it's also prone to accidental usage: Sometimes I'll holdclick a slider and accidentally enable keyboard input. I also dislike the idea of making a user wait to do something. The click-then-type method is also undiscoverable, and also clears the current value from the field for the purpose of editing the value. In my ideal, all sliders in Krita would have an explicit spinbox like in other painting software such as CSP and PS, without the current merging of the slider and spinbox components. Again, this would likely necessitate artist discussion. The current sliders might be more "compact", but in my opinion they are not as intuitive and usable as they could be.
Might be worth noting that a user can apparently slap a bandaid over many cases of this issue: As of 5.2, the whole set of number keys allotted to canvas inputs by default (1-6) can be moved over to their equivalent Keyboard Shortcuts. In the case of Pan Mode's relation with Spacebar, there is no workaround besides setting Pan Mode to an input that isn't stolen by value input, since there is no Keyboard Shortcut equivalent for Pan Mode.
I wonder if the delay is necessary for *all* keyboard input? My problem is mostly that "Alt" doesn't work right if mapped to a keyboard shortcut, although I understand that may also be in part due to it just being a "special" key. There is no problem using the color picker right after interacting with an UI element as long as the picker is mapped to ctrl or space. Possibly other keys would work too, I haven't tested. Why is this? Are these keys whitelisted from the delay? Or is my issue separate from this UI focus delay after all?
*** Bug 462894 has been marked as a duplicate of this bug. ***
*** Bug 476405 has been marked as a duplicate of this bug. ***
The above report brings up the case of the layer blending mode dropdown, which I often find to be very annoying. Generally after I press space after selecting a new blending mode, it will open the dropdown again, instead of panning the canvas.
(In reply to tomtomtomreportingin from comment #14) > The above report brings up the case of the layer blending mode dropdown, > which I often find to be very annoying. Generally after I press space after > selecting a new blending mode, it will open the dropdown again, instead of > panning the canvas. The case of the blending mode dropdown is a bit different than the other instances of focus issues I've experienced: focus doesn't switch from the dropdown no matter how long you wait after moving the cursor over the canvas.