mirror of
https://github.com/keycastr/keycastr.git
synced 2026-05-15 14:15:50 -06:00
[GH-ISSUE #248] No character shows when type non-latin keys. #209
Labels
No labels
bug
compatibility
discussion
documentation
enhancement
help wanted
help wanted
investigation needed
pull-request
release
visualizer
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/keycastr#209
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @arafune on GitHub (Oct 18, 2022).
Original GitHub issue: https://github.com/keycastr/keycastr/issues/248
I'm Japanese and use Japanese keyboard normally. While I enjoy using this app, but I have one request. Even when I type "Eisu" (to change "Kana" mode to ascii mode") key or "Kana" (vice versa) key in Japanese keyborad. no character appear appear in the window. Just a space (but not under bar like character) shows.
As I have not check the code, I don't know if this app accepts non-latin key board. But I believe you can fix the problem.
You may wander what is the appropriate symbol for "Eisu" key and "Kana" key, but if any character not just a space is really nice.
Please think about it.
@akitchen commented on GitHub (Nov 8, 2022):
Hello, thank you for opening an issue.
The app should work with non-latin keyboards, but I would like to better understand the problem you are having. It sounds like the Japanese-specific language keys are not properly supported. I'm not surprised, since we hard-code glyphs for certain other special keys. If we want to display a special character when these keys are typed, we may need to special-case their key mappings.
Separately, I understand that these keys are used to change the language input modes. If you switch to that input mode before starting keycastr, does it work correctly otherwise? The app may need to do a better job of supporting changes to the keyboard layout after it has started.
@arafune commented on GitHub (Nov 9, 2022):
Thank you for your reply. If the special characters are hard-coded, it is reasonable those keys are not displayed. I'm really happy if you treat these keys as the special key.
Yes, your guess is right. These keys are used to change the language input mode.
And the app works well excepting the problem I met (not-display the character for some key such as "Eisu" and "Kana".). And the input mode change does not affect when the app starts, it always works well.
@arafune commented on GitHub (Nov 10, 2022):
By using Keycode (https://apps.apple.com/jp/app/key-codes/id414568915?mt=12), I have checked the key code of the corresponding keys.
Note that this app shows the following when I press down key "a":
Characters: a
Unicode: 97/0x61
Keys: A
Key code : 0/0x0
I believe this key code is same as yours.
When I press "Eisuu" key, the output is:
Characters:
Unicode: 32/0x20
Keys:
Key Code: 102/0x66
When I press "Kana" key, the output is:
Characters:
Unicode: 32 / 0x20
Keys: 104 / 0x68
I hope this information helps you.
Sincerely,
@akitchen commented on GitHub (Nov 10, 2022):
Hello and thank you for looking further into this. This information is also available in some of the headers for Apple's ancient Carbon framework:
I am planning on adding the following code to the hardcoded mappings in the keystroke transformer class:
Could you please validate these strings for representing Eisuu and Kana keys, and also comment on whether the other keys listed above currently work correctly with a JIS keyboard? It doesn't look like I can test them using a virtual keyboard in macOS.
In particular, do the Japanese vs. English/Roman comma keys display correctly? I believe it should be
、vs,or，. Of course the Yen key should also work, and I am unfamiliar with the special JIS underscore key.Thanks again
@arafune commented on GitHub (Nov 11, 2022):
Thank you for your reply:
/* JIS keyboards only*/
enum {
kVK_JIS_Yen = 0x5D,
kVK_JIS_Underscore = 0x5E,
kVK_JIS_KeypadComma = 0x5F,
kVK_JIS_Eisu = 0x66,
kVK_JIS_Kana = 0x68
};
The above is consistent with my key code.
And I should say that
is ok, because "英数" is read as "Eisuu" or "Eisū" and "かな" is read as "Kana".
Yen character has already appeared in the App.
Regardless of the imput modes, the roman type comma "," is shown. I believe this is not the problem. The role of this app is showing what key I press. While I press "shift" and "1", the app shows the "upper arrow" and "1", not "!". Thus I think it is consistent that roman comma shows everytime.
On the other hand, the problem I met is that no character is shown while I press "Eisuu" / "Kana". I feel this is inconsistent behavior which we have expected.
Sincerely,
@akitchen commented on GitHub (Nov 14, 2022):
OK the above fix is available on the main branch and will be included in the next release.
@arafune commented on GitHub (Nov 14, 2022):
Thank you very much for your quick response.
I cannot have built the app, (probably) becasue I'm not familiar with XCode. Whie I try to build, some errors (Some frameworks are missed.) occur. I believe that this problem occurs because I don't know how to use xocde, not because of the code. Anyway I expect the new release version works well.
@arafune commented on GitHub (Nov 20, 2022):
0.9.13 Works completely well. Thank you very much.