[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 wolthera changed: What|Removed |Added CC||art.ramirez.morales@gmail.c ||om --- Comment #12 from wolthera --- *** Bug 462894 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 --- Comment #11 from rebuilders...@gmail.com --- 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? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 --- Comment #10 from tomtomtomreportin...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 --- Comment #9 from tomtomtomreportin...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 --- Comment #8 from tomtomtomreportin...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 Dmitry Kazakov changed: What|Removed |Added CC||dimul...@gmail.com --- Comment #7 from Dmitry Kazakov --- 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 :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 Halla Rempt changed: What|Removed |Added CC||ha...@valdyas.org --- Comment #6 from Halla Rempt --- Yes, alt is special on Linux and Windows. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 --- Comment #5 from rebuilders...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 Halla Rempt changed: What|Removed |Added CC||rebuilders...@gmail.com --- Comment #4 from Halla Rempt --- *** Bug 457945 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 tomtomtomreportin...@gmail.com changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 radian changed: What|Removed |Added CC||xeny...@gmail.com --- Comment #3 from radian --- 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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 --- Comment #2 from tomtomtomreportin...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 --- Comment #1 from tomtomtomreportin...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440399] Focus between UI elements and canvas doesn't switch fast enough, often leading to clashing functionality of hotkeys
https://bugs.kde.org/show_bug.cgi?id=440399 tomtomtomreportin...@gmail.com changed: What|Removed |Added Summary|Focus between UI elements |Focus between UI elements |and canvas don't switch |and canvas doesn't switch |fast enough, often leading |fast enough, often leading |to clashing functionality |to clashing functionality |of hotkeys |of hotkeys -- You are receiving this mail because: You are watching all bug changes.
