-
-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enhancement(LorieView.java): improve input handling #768
base: master
Are you sure you want to change the base?
Conversation
@twaik There is still a delay when typing in Korean, SHANA.korean.input.mp4 |
The solution is created for software keyboard, I did not try to fix hardware keyboard. |
@twaik |
In Android Studio if I click the Debug button using this PR, then reproduce the crash, the debugger does not seem to print any backtrace, but this appears in logcat snippet
termux-info of the testing device
|
24ef1b0
to
bec5fda
Compare
Software keyboard only.
Can you please try again? |
@robertkirkman And what software keyboard layout did you use? |
I mean I used gboard and it was fine on my device. |
bec5fda
to
8de8ce3
Compare
8de8ce3
to
e7fbf10
Compare
It lets us use cursor control, keyboard suggestions (with word replacings!) and some other stuff. Screen_Recording_20241211_172139_TermuxX11.mp4 |
Korean input seems to be a bit more weird. Screen_Recording_20241211_172818_TermuxX11.mp4 |
@twaik
Screen_Recording_20241212_005155_TermuxX11.mp4 |
@twaik This is the main reason why #620 needs to test the language used for Gboard and decide the input type dynamically. It would great if such behaviour can be suppressed. |
The cursor movement isn't usable on LatinIME |
I did not find cursor control feature there. Probably it is not available there. |
I used GBoard in Turkish mode, and now I have tested the current version, and the crash is not happening anymore in the same test, Backspace is now working. I believe the update you created fixed the problem. Now I will describe a second problem that I noticed, which I believe I noticed happening at least once in both the original and the revised versions of this PR, and I am not sure how important this is because it seems like it only happens in Chromium and when I try to reproduce it in Firefox it never occurs, or at least I have not noticed it happening for approximately 20 minutes of testing firefox. Since Chromium is in tur-repo but Firefox is in x11-repo, I am not completely sure how high-priority this would be since it could be specifically just an issue with Chromium. What happens is, very occasionally, a symbol will appear that is different from the symbol that I touched, but only for one key stroke, and then the next touch of the same button produces the correct symbol. Here is a video of that happening, at the timestamp in the video where it happened, 2:25, where for one key stroke, "é" became "í", and then "é" appeared on the next touch of the same button. https://youtu.be/jAVW-7wSjug?si=Fo8O9Hv0lQyf9yua&t=145 |
screen-20241212-165829.mp4 |
seems fine with gboard chinese handwriting and cantonese input for now logs like this appeared while typing tho, there seems to be one keysym log every character typed
|
the |
Making LorieView handle korean/chinese/turkish/other languages requiring composition and composed symbols.
@knyipab can you please test this? It replaces #620 solution.
@813ethan @ilhan-athn7 @robertkirkman @hansm629 can you please test this too?