Long press numbers chooses wrong default punctuation

[GoogleCodeExporter]

Long press on a number to get default punctuation instead of choosing from 
menu.  Symbol generated is not that shown on the key cap but a more obscure 
choice.

Nook color; cyanogenmod 7.02

Original issue reported on code.google.com by cs07...@gmail.com on 24 May 2011 at 4:01

[GoogleCodeExporter]

I agree, if I select spanish language I should obtain áéíóú as default in 
long press character, because I don't need others characters in my language. 
Why I have to select my language if nothing happens...

Original comment by lmf...@gmail.com on 24 May 2011 at 8:27

[GoogleCodeExporter]

Does this apply to the 4-row or 5-row keyboard, or both? You're supposed to get 
a popup menu on long press, you're not seeing that when you keep pressing down? 
Can you give an example of the symbol you're getting, and try pressing down in 
different parts of the key (near left or right edge) to see if you get the same 
symbol or if it changes?

The language settings are currently intentionally ignored as a workaround for 
issue #1 since it was causing conflicts with the built-in keyboard, I'm looking 
into a better internationalization fix.

Original comment by Klaus.We...@gmail.com on 25 May 2011 at 5:24

• Changed state: Accepted

[GoogleCodeExporter]

There is a popup menu, but my expectation (based on other keyboard) would be 
that if I simply lift my finger from the key without sliding it into the popup 
menu, this would produce the "default" symbol show on the upper corner of the 
keycap.

For example, on the 1 key is the !, but when I long press that, I get the 
inverted version (used at the start of a sentence in Spanish).  If I try the 3, 
I get a diamond rather than a #.  The symbol that results is not always the 
first on the popup menu, so there is being a consistent default selection from 
each menu - it's just the wrong default selection.

In legacy mode, it does correctly choose the number as a default, rather than 
one of the additional symbols available from the popup menu.

So I suspect that in extending the keyboard layout, something was mixed up in 
the assignment of default selections.

Original comment by cs07...@gmail.com on 25 May 2011 at 5:53

[GoogleCodeExporter]

The problem is that there is no "default selection" as such in the layout 
definition. The way that the popup keyboards work is that the highlighted 
character is always the character that happens to be nearest to the finger 
contact point. The code tries to shift the mini keyboard left or right in an 
attempt to align a digit in the leftmost or rightmost position with the key 
(finger) position, but this is very restricted and only works right under 
certain circumstances. including the requirement that the edge character must 
be a digit. The 4-row keyboard carefully selects characters to ensure that for 
example the keys near the middle ("t", "y") don't have too many alternates so 
that the mini keyboard fits in less than half the screen width.

I think that consistency is important in the 4-row keyboard since a main use 
case is support number keys without having to shift keyboards since they aren't 
otherwise easily available.

I had decided to mostly ignore the restrictions for the full layout, since it 
seemed that using the shift key is more common than long-pressing, and digits 
are of course available directly. I felt that it's more useful to have a wide 
selection of alternate characters available, and I reinterpreted the on-key 
hint symbols as showing the shifted chars, and not necessarily the default 
long-press char. I had tried to get it working consistently, but it looked like 
that wasn't possible without code changes, since the assumption that the 
intended "default" character is a digit isn't true for this layout. It would be 
possible to modify the keyboard definition XML spec to support explicitly 
declared default characters, but that would be a fair amount of work.

How strongly do you feel about this issue? Do you prefer using long-press over 
using the shift key? And have you tried multitouch shift?

Original comment by Klaus.We...@gmail.com on 25 May 2011 at 6:16

[GoogleCodeExporter]

This issue was closed by revision 9a57cf87aeae.

Original comment by klausw@google.com on 26 May 2011 at 12:52

• Changed state: Fixed

[GoogleCodeExporter]

I think I got it fixed, can you please try out the release candidate and let me 
know if that works as you expect? 
http://code.google.com/p/hackerskeyboard/downloads/detail?name=HackersKeyboard-v
1012rc2.apk

Original comment by Klaus.We...@gmail.com on 26 May 2011 at 12:59

[GoogleCodeExporter]

hi, now it works as cs07 says,  but I wanted to say that if I select spanish 
keyboard I ought to have áéíóú without sliding my finger across the mini 
keyboard long press. Default long press àèīøū as you have in your kayboard 
is not useful in any language. Thanks.

Original comment by lmf...@gmail.com on 26 May 2011 at 1:42

[GoogleCodeExporter]

Can you try v1.12rc3? I've reactivated internationalization, and it should do 
the right thing if your language (or keyboard) is set to Spanish. 

http://code.google.com/p/hackerskeyboard/downloads/list

Original comment by Klaus.We...@gmail.com on 26 May 2011 at 3:18

[GoogleCodeExporter]

Hi, thanks, now it's working as I wanted except for íú, because default is 
now üï, but it works for áéó. Thanks.

Original comment by lmf...@gmail.com on 26 May 2011 at 5:37

[GoogleCodeExporter]

Sorry I forgot to say it doesn't work for capital letters either ÁÉÍÓÚ 
it's like previous version for capital letters. Thanks for your attention...

Original comment by lmf...@gmail.com on 26 May 2011 at 5:44

[GoogleCodeExporter]

HackersKeyboard-v1012rc2.apk is now producing the keycap symbols as defaults on 
long press in portrait mode.

However, in landscape mode (which I had not previously tried) long pressing 
does not generate any character at all.  Sliding into the popup menu does 
produce the selected symbol.  

Original comment by cs07...@gmail.com on 26 May 2011 at 5:53

[GoogleCodeExporter]

I'll look into the uppercase letters, this is currently configured through 
separate character lists but it should be possible to do automated uppercasing 
as a fallback.

The landscape mode issue sounds odd, it works for me. Does the popup menu show 
the expected characters? Do you see the orange box surrounding a character as 
you move your finger horizontally? Is this for all languages, or just when 
selecting Spanish? What phone and OS is it?

Original comment by Klaus.We...@gmail.com on 26 May 2011 at 6:41

• Changed state: Accepted

[GoogleCodeExporter]

Landscape works for me too as well as portrait. Acer Iconia Tab A500. Will you 
fix íú default long press for iu in Spanish keyboard? Thanks

Original comment by lmf...@gmail.com on 26 May 2011 at 7:00

[GoogleCodeExporter]

Please try the latest release candidate (>= v1.12rc5), this should fix the 
uppercase alternate characters and "íú" defaults.

http://code.google.com/p/hackerskeyboard/downloads/list

Original comment by Klaus.We...@gmail.com on 27 May 2011 at 12:53

[GoogleCodeExporter]

Hi: thanks, now it's working perfect.

Original comment by lmf...@gmail.com on 27 May 2011 at 1:45

[GoogleCodeExporter]

Thanks for confirming - the latest release should be on the Market later today.

Original comment by Klaus.We...@gmail.com on 28 May 2011 at 6:21

• Changed state: Fixed

[GoogleCodeExporter]

Bulk update - changing "Fixed" to "Verified" for old bugs.

(Background: I'm changing the "Fixed" status to be considered open, the next 
steps in the lifecycle will be the closed states "FixInTest" and "Verified". 
This lets me mark issues as "Fixed" in commit messages without hiding them from 
the issue tracker.)

Original comment by Klaus.We...@gmail.com on 22 Jan 2013 at 7:33

[GoogleCodeExporter]

Bulk update - changing "Fixed" to "Verified" for old bugs.

Original comment by Klaus.We...@gmail.com on 22 Jan 2013 at 7:34

• Changed state: Verified