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

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by hvsrivat...@gmail.com on 8 Mar 2012 at 1:49

[GoogleCodeExporter]

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.

Original comment by Klaus.We...@gmail.com on 8 Mar 2012 at 7:05

• Changed state: Accepted

[GoogleCodeExporter]

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?

Original comment by hvsrivat...@gmail.com on 9 Mar 2012 at 9:35

[GoogleCodeExporter]

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.

Original comment by Klaus.We...@gmail.com on 10 Mar 2012 at 6:31