In OS = Windows 11 and Krita 5.2.2(lastest version),
I wonder if Krita detect a shortcut key by a fully match method, aka, if F10 is not included in any shortcut key, a F10 + Ctrl + Shift + A will not trigger anything in Krita. By the way, the similar key stroke F10 + Ctrl + D will trigger deselection on PhotoShop.
It seems not a problem at all, but here’s my concern.
Shortcut Failure “Bug” From 2 years ago
An shortcut problem had been raised by some users two years ago in this forum (Abnormal canvas rotation and shortcut keys failure), which in most cases was caused by WeChat. For some reason, WeChat will press a virtual key F22 while started and not release that key at all.
Simple Test C++ Program
I wrote a simple C++ program to simulate what WeChat do at the opening:
#include <windows.h>
INPUT onlyPress[] = {
INPUT {
.type = INPUT_KEYBOARD,
.ki = {
.wVk = VK_F22,
}
}
};
INPUT pressAndRelease[] = {
*onlyPress,
INPUT {
.type = INPUT_KEYBOARD,
.ki = {
.wVk = VK_F22,
.dwFlags = KEYEVENTF_KEYUP,
}
}
};
int main(int argc, char* argv[]) {
SendInput(1, onlyPress, sizeof onlyPress);
// SendInput(2, pressAndRelease, sizeof pressAndRelease);
return 0;
}
If WeChat pressAndRelease that key, Krita works normal, but WeChat didn’t. It onlyPress that key and never gets it released. You could run this program and for me it 100% causes Krita 5.2.2 to lose signal from Ctrl, Alt, Shift and Space, meaning a lot of shortcuts won’t work anymore. Only a restart of Krita (or an lock-then-unlock of Windows) will fix this, very annoying.
I use a software quicker to detect the keyboard state, aka which key has been pressed, including virtual keys, and release that virtual key after test.
Along side holding virtual key, a constant hold of a physical key that doesn’t bind to anything like F10, will also make Krita’s shortcut fail, just like I mentioned at the top of this post.
More Issues from the Shortcut Recognization Method of Krita
In fact, WeChat is just a common case. I found a recent report on a software pressed HanjaMode virtual key and not releasing it, causing Krita’s shortcut to fail, well, again. (This report in Chinese Baidu Forum, on 2024/1/25)
So, there are always some softwares that don’t follow a normal way, and hold a key for a long time.
My Hope
I know that it’s impossible for me to change Wechat’s source code. Even if I managed to do that, other irregular software does exists that will cause the same problem. But Krita is open sourced, so I have my hope here to not lost this loving drawing software because of some kind of bug.
I hope we could add some protections on this problem(just like PhotoShop and many other still-fine softwares that won’t be affected by bad softwares like WeChat).
If the question “if Krita detect a shortcut key by a fully match method” has its answer to be “yes”, then we can change it to a partially match method, which will solve the problem in my guess.
Partially Shortcut Match Method
I mean, when additional key is pressed, such as a manually pressed F10, or an auto pressed F22, we ignore that key since it doesn’t exists in shortcut key table. So that F10 + Ctrl + Shift + A can also trigger deselection in Krita, because we ignore F10.
There might be other solutions better than this according to Krita’s software architecture. I will assume the problem code is in something related to key stroke parsing.
Currently I’m trying to go through Krita’s source code to locate the problem code.
What’s your opinion on this topic? Please let me know!