-
-
Notifications
You must be signed in to change notification settings - Fork 95
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
More cursor keys #925
More cursor keys #925
Conversation
This PR appears to be small enough so I can handle it, but in the future: please avoid putting multiple things into a single PR.
I don't really care. The current long-press behavior was added by @codokie, so I'd follow their opinion here. |
app/src/main/java/helium314/keyboard/keyboard/internal/keyboard_parser/floris/KeyCode.kt
Outdated
Show resolved
Hide resolved
Do you mind PRs that aren't linked to an issue, then? I could open a feature request for each one of these changes, but I don't want to create more work with redundant write-ups. I'll always try my best to explain what's going on in these PRs, of course. I'll also note that combining these features was slightly helpful since the changes to Key.java for the new keys depend on the repeating-arrow-key change, but I understand your gripe. I could open pull requests for branches-of-branches and mark them as dependent on other PRs, not sure how you'd feel about that. I hope you'll pardon my naivety with this stuff, I'm still very inexperienced with git and code contributions :) |
I would say these are essentially liked to the text editing layout you're working on. No need to have a separate issue for each of those parts.
I'd prefer just having one PR after another. I see that with the |
Alrighty, that's what I'll do moving forward. The forward/word-delete keys branch I'm working on is based on this one. |
Basically you can't. Terminal emulators and a few other things don't tell you the text. It's possible to guess some text because what you entered is cached, but this may not be the correct text in some specific cases.
Is this about up/down arrows? If yes, then it should not be relevant for this PR, because except for repeating they do the same as before.
I don't think you can simply fine-tune this behavior. To me it doesn't seem that bad actually. In any case I would recommend to use the simle approach first, as it's very easy to make things overly complicated and then end up with a ton of weird edge cases.
Possibly the drawable could be adjusted, not sure what it's used for other than the toolbar keys. |
Arrow keys are all rotations of arrow_left. The material/rounded shift key icons and a few others are also derived from the arrows. I could do a PR that creates new drawables I've tried that, with difficulties. I'm not sure if/how you can make
You can approximate it for the lefters (word-left, up, etc.) with the canDeleteCharacters method. It'll false-positive in cases where the left/up arrow would leave the input field, but this is negligible since it'd only be used to prevent audio clicks FTTB. It's an unexpected edge-case anyways, so it doesn't need that fine-grain of polish. It's more complicated for the righters. A parallel "canForwardDeleteCharacters" (which will be helpful later) can be implemented by testing if the text after the cursor is empty, but it's less reliable than its counterpart since, as you say, you don't always have access to the full text. Strange how |
This is imo pretty horrible to handle in Android.
As far as I remember it only works if you typed the text and do not close the keyboard between typing and checking. Since terminal emulators usually don't report information about the existing text, I don't think you can get information on how many characters are available to the right. But you're right,when it's just about haptic/audio feedback it's fine when it doesn't work correctly in some special cases. |
Yeah, since it's just for feedback the methods can be recycled for the arrow keys. The arrows want to repeat sound when there are characters to the right/left of the cursor. The vertical arrows will move the cursor to the start/end of the input field before exiting it, so the same checks as the horizontals can be used and it should be consistent. The canForwardDeleteCharacters check should only fail slightly more often than its counterpart, and only in those primitive cases. |
Splitting this in two, to make things more legible. |
This patch implements toolbar keys for the following previously-reserved codes:
It also adds a new pair: word left/right.
Other changes:
Remaining hiccups:
Would appreciate the input of anybody with knowledge on these topics.
Progress on #357