-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Added support for pageup/pagedown using Fn-Up and Fn-Dn key combos on… #783
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
Conversation
You only fixed half of the OP. Fn+Left/Right were expected to be Home/End respectively. Though I am not sure if it's really our problem to fix anyway. While the modifications might sound sensible, I don't know if they are universal enough that it's fine to hard code them in the app... |
You only fixed half of the OP. Fn+/Left/Right were expected to be
Home/End respectively.
True, I forgot about those. Mea culpa.
Though I am not sure if it's really our problem to fix anyway. While
they might sound sensible, I don't know if they are universal enough
that it's fine to hard code them in the app...
I'm not sure about that either, but we're kind of stuck here on this device. My alternative fix is to make a hack at the Linux keyboard driver level and report physical page up and page down presses when
detecting the key combo, but that's not right too - the driver should simply report the scan code, and do not any interpretation, I guess.
The reason I think fixing in termux might be ok is because a number of other applications are reported to register pageup/pagedown properly with thes key combos. The page up and page down keys seem to be a bit
neglegted in Android anyway, since not much devices are equipped with a physical keyboard. I found these comments in KeyHandler.java:
````
// Note that KEYCODE_HOME is handled by the system and never delivered to applications.
// On a Logitech k810 keyboard KEYCODE_MOVE_HOME is sent by FN+LeftArrow.
````
so there seems to be something similar going on on the k810 keyboard.
I will follow your advice here: if you think this should not go in Termux, I'll drop the pull request and go have a beer. If you are willing to take it in, I'll make sure to add home/end as well - which is trivial, of course.
I hope for the latter, of course. The Gemini is a one of a kind device, and it really goes hand in hand with Termux: I know of no other devices which are this compact and have a decent keyboard. It's a shame to let this chance pass to
have such a great device properly support Termux :)
Thanks,
|
I feel like there are quite a many Gemini PDA users that are at the same time Termux users, me included, that are pretty frustrated by the pgup/pgdown issue that this fixes and thought that it might make a difference. It might not be ideal way to fix this but sadly Android is the cause of that some text editors have made this functionality in the way that Zevv proposes. Regards, Sami |
I just added support for Home and End and proper handling of modifier keys on all keys. |
4c8cf13
to
03168fa
Compare
case KEYCODE_DPAD_RIGHT: | ||
return (keyMode == 0) ? (cursorApp ? "\033OC" : "\033[C") : transformForModifiers("\033[1", keyMode, 'C'); | ||
if((keyMode & KEYMOD_FUNCTION) != 0) { | ||
return transformForModifiers("\033[1", keyMode, 'F'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if you need the 1
when Ctrl/Alt/Shift is involved but when neither of them is, it will return \033[1F
, which is wrong?
case KEYCODE_DPAD_LEFT: | ||
return (keyMode == 0) ? (cursorApp ? "\033OD" : "\033[D") : transformForModifiers("\033[1", keyMode, 'D'); | ||
if((keyMode & KEYMOD_FUNCTION) != 0) { | ||
return transformForModifiers("\033[1", keyMode, 'H'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
…ard, Fixes termux#731. Fn+Left -> Home Fn+Right -> End Fn+Up -> Page Up Fn+Down -> Page Down
03168fa
to
50fe003
Compare
Quoting tomty89 (2018-07-25 19:15:12)
tomty89 commented on this pull request.
> case KEYCODE_DPAD_RIGHT:
- return (keyMode == 0) ? (cursorApp ? "\033OC" : "\033[C") : transformForModifiers("\033[1", keyMode, 'C');
+ if((keyMode & KEYMOD_FUNCTION) != 0) {
+ return transformForModifiers("\033[1", keyMode, 'F');
I don't know if you need the `1` when Ctrl/Alt/Shift is involved but when neither of them is, it will return `\033[1F`, which is wrong?
You're right - it seems that all the applications and systems I tested
this on *do* work with the additional `1` though, so that is why I
missed this.
I now checked all the output by verifying all keys and modifiers
byte-for-byte against desktop linux xterm, pull request updated.
|
I think I've found the reason why these combinations don't work in Termux. When there's a key event, Termux checks if it has any Ctrl/Alt/Shift modifiers. It doesn't check other modifiers, like Function. This causes Termux to mistake Fn+Up for Up, and handle it as such. If the bug is fixed so that Termux correctly tells Android it has no idea what this Fn+Up combination is, Android will then check if the keyboard config defines a fallback key. In case of Gemini, the fallback is Page Up. So Android gives Termux a Page Up event, which Termux already knows how to handle, and everything works. See my longer explanation: #731 (comment) |
Closed in favour of #794. |
This fixes issue #731