#205 Long press on e or u inserts 3 or 7 instead of E or U

[Anonymous]

Originally created by: hvsrivat...@gmail.com

What steps will reproduce the problem?

1. Set up the long press (300ms) to change to the capitalized letter.
2. Long press e or u in the center (normal position as for other letters).

What is the expected behavior? What do you see instead?

-On long press, I expect to get E for e and U for u.  Instead, I get 3 for e and 7 for u.  Turning on the debug mode shows that the keypress position is correctly in the center.  Only if the press position is quite towards the LEFT on e and towards the RIGHT on u, then I get the correct capital letter.  This is not the natural position.

All other letters are okay.  (Great app BTW!)

What version of Hacker's Keyboard are you using? (See "Debug" section at
the bottom of the app's Settings menu.)

1.31.1311

On what phone or tablet?

HTC Incredible

If applicable, does this affect the 4-row or 5-row layout, or both?

Only tried the 4-row layout.

Which
language(s)?

English.

Please provide any additional information below.

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

The popup keyboards don't actually have the concept of a default or primary character, this works indirectly through aligning the popup to put the leftmost or rightmost one under the user's finger.

Unfortunately this breaks once the popup menu gets too full to fit in the properly-aligned location, since it'll shift position to prevent keys from ending up offscreen. This happens more frequently when adding the shifted and capital letters to the popups, since it wasn't originally designed to do so.

I'll think about a workaround, for example shrinking the "keys" of the popup keyboard if it detects that it's getting too big, but it's not an easy fix since it depends on the detailed layout geometry and dynamic contents of the popup keyboard. Or it may be possible to clip the popup layout, effectively removing rarely-used ones when it gets too full.

I'd prefer to defer this and work on the user-editable layouts instead for now since that would also solve the issue while being more generally useful, you could simply remove some characters from the alternates in a case like this. See issue 13.

Status: Accepted

[Anonymous]

Originally posted by: hvsrivat...@gmail.com

Thanks for the quick response.  I understand the issue and I look forward to the enhancement for user-editable layouts.  Any guesses on an ETA?

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

My current ETA estimate is summer of 2022, based on the assumption that I'll need 5 full days to get it fully implemented, and that I'm currently averaging about 1h/week of time available to work on the keyboard, with 55 minutes of that doing support and routine updates.

More seriously, I'm hoping I'll find some larger chunks of time to work on it, and hopefully it'll be done significantly sooner than that.