Quote:
Originally Posted by Frenzie
There has to be a way to avoid dealing with direct button events? Similar to how pasting works on Android, and how we've done the input on SDL. Because implementing keyboard layouts other than QWERTY (or whatever the dev prefers) would be patently ridiculous.
|
Copy / paste also goes through JNI but it is cheap because it is impossible for the user to copy/paste stuff a few times per second.
The input model of the SDL port is what I had in mind when I talked about "getUnicodeChar". The function can be called through JNI from
https://github.com/koreader/koreader...droid.lua#L115. We just need to get a few more values from "android.lib.AKeyEvent_*" such as the key modifiers aplied for current stroke.
The function will return 0 if the key isn't intended to be translated to unicode (ie: the back key) and a positive value that can be casted to a char otherwise.
That unicode char already handles keyboard l10n/distribution and works for both hardware keyboards and other IMEs.
It just happens it is slow to be called in that loop, even if we do that only when we want to register keyboard events, like we're doing on SDL.
So my suggestion would be: in inputState mode we don't consume key events in native code so they can be sent to managed code where we can do getUnicodeChar without the JNI penalty.
Please do notice that, with current approach, almost all key events won't be catched from JVM as we do consume them in
https://github.com/koreader/koreader...droid.lua#L208