Arian04
commented
3 months ago so I was confused about why alternate layouts didn't already work, given how the code was written. Seems the culprit is that I'm getting bad data in my key listener for the Russian layout you mentioned. Only thing filled in is the character itself, but no straight up keycode or anything, since it's always just sending 0s for those. Gonna try and see the cleanest and most extensible way to add support for these situations.
edit: also other people online have mentioned this issue existing. I'm technically abusing the keylistener API and all the docs say that it's not guaranteed to work properly with soft keyboards, but back when I first wrote this portion of the app, it was the only reliable way I could find. Maybe I'll replace it with something else later.
update: I think I've figured out a better way. Maybe it'll solve this, maybe it won't. Hopefully it will though.
Is your feature request related to a problem? Please describe. So. A lot of people are going to use this on non-english keyboards, myself included. Maybe, it would be a good idea to add some kind of character→keycode handler for non-QWERTY layouts? Perhaps, files from Linux's keyboard layouts folder (
/usr/share/kbd/keymaps/i386/)?Describe the solution you'd like Ideally, this should be something like a setting that allows you to pick your used keyboard layouts, a quick switcher in the input activity to pick which layout you are currently using, and maybe an option to handle all layouts simultaneously for when they do not conflict with each other (say, english qwerty and russian йцукен)? So, pressing
Лwould send thekkeyevent, as that is the key that corresponds to Л on the Russian layout.Describe alternatives you've considered I've tried using Hackers Keyboard with explicitly drawn russian chars. It was a pain to handle.
Additional context