Pressing shift twice doesn't lock keys on the 5th row

[GoogleCodeExporter]

What steps will reproduce the problem?
1. press shift, the keys on the 5th row are locked (alternative keys displayed, 
just as letter keys)
2. press shift again, 5th row changes back to its default state, while letter 
keys stay locked
3.

What is the expected behavior? What do you see instead?
Pressing shift twice should lock the 5th as well.

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

On what phone or tablet?
P1000, running Android 2.3.4, or its emulator

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

Which language(s)?
English.

Please provide any additional information below.

Original issue reported on code.google.com by jerryfle...@gmail.com on 13 Jun 2012 at 10:16

• Merged into: #177

[GoogleCodeExporter]

This is intentional, it implements "caps lock", not "shift lock". I had mainly 
implemented this for use with keyboards such as French "AZERTY" that have 
letters on the top row.

I could add an option to let the user select between "shift lock" and "caps 
lock", but I'm curious why you prefer that behavior. Do you frequently need the 
top row punctuation together with uppercase letters?

Original comment by Klaus.We...@gmail.com on 14 Jun 2012 at 5:52

• Changed state: Accepted

[GoogleCodeExporter]

It turns out the only usecase of this keyboard for me is to open connectbot and 
begin a shell session, where punctuation characters are of equal importance to, 
or even means more than, alphanumeric ones. It would be very awkward to input, 
for example, the following command:

a_cmd 2>&1 | b_cmd %.!*@(com)

I would like to stay into the upper case state so as to input punctuation 
characters continuously, just like a standard PC keyboard (US layout, 104 
keys), for otherwise it is very boring to switch back and forth.

Original comment by jerryfle...@gmail.com on 14 Jun 2012 at 10:15

[GoogleCodeExporter]

Please follow issue 177 for the feature request to add Shift Lock as an option.

I'm still not sure why you think this would be more useful - in your example 
above, you'd be able to type "2>&1" like this in the current setup:
  "2" Shift ">" "Shift" "&" "1"
  "2" Shift hold ">" "&" Shift release "1"

A shift lock would add the following sequence as an option, that's more 
keystrokes:
  "2" Shift Shift ">" "&" Shift "1"

I think sequences of 3 or more shifted punctuation characters are fairly rare 
even in command line use, and not frequently combined with uppercase 
characters, but this may vary based on your shell or language - I don't 
recognize the "%.!*@(com)" syntax, though some Perl expressions get close to 
that.

If I do get customizable keymaps working (see issue 13), I think it would be an 
interesting variant to do an AZERTY style layout where the 5th row is swapped, 
with punctuation by default and digits reachable via Shift.

Original comment by Klaus.We...@gmail.com on 15 Jun 2012 at 5:45

[GoogleCodeExporter]

The VERY annoying aspect here, for a french AZERTY user, is that the digits row 
doesn't stay locked (instead, on double tap of the shift key, the accented 
upper case letters appear) - so, it is now no longer possible to type a number 
(or one should go to the Fn screen).
Accented upper case letters are so seldom used in French, that this feature 
does not seem worthwhile. digits are much more often used!
Please comment on this observation.

Original comment by bob.walr...@gmail.com on 15 Jun 2012 at 9:33

[GoogleCodeExporter]

So an option to choose between SHIFT_LOCK and CAPS_LOCK is fair enough.

Original comment by jerryfle...@gmail.com on 17 Jun 2012 at 2:58

[GoogleCodeExporter]

Ok, you've convinced me, I'll look into adding a shift lock option.

I'm still curious though how/why you are using the lock - I was assuming that 
it was largely used for sequences of uppercase characters, where uppercasing 
the accented characters would be more consistent, but it sounds as if Bob is 
primarily using it as a "num lock" for the AZERTY layout to get digits, and 
Jerry is using it as punctuation lock, and you are both not really interested 
in entering multiple uppercase letters? If that's true, I'm wondering if a 
separate shift key or mode may be more useful that just toggles the non-letter 
keys and leaves the letters unchanged, but that would be a nonstandard layout 
that would be more appropriate for a user-customized mapping.

Original comment by Klaus.We...@gmail.com on 18 Jun 2012 at 7:49

[GoogleCodeExporter]

It would help me, and all other programmers, I guess, more if the keyboard acts 
in a standard way with its behavior regarding shift states. It is useful for 
example, when one wants an all-uppercase constant, or a magic positional shell 
variable ${1#+*#} (this is to trim the first positional parameter, or am I 
wrong?) As the name suggests, this is a PC keyboard, and features a standard 
compliant layout which mainly benefits special key input. If one want localized 
support, for example, to input Chinese or French, I would suggest Latin IME or 
Google IME. Even hackers keyboard supports multiple languages, it is still very 
inconvenient to use it to input a normal sentence in any language simply 
because the keys are so small, especially on small screens, when 5-row layout 
is active.

Original comment by jerryfle...@gmail.com on 18 Jun 2012 at 11:09

[GoogleCodeExporter]

I'm still confused - typical US QWERTY keyboards have a Caps Lock key, not 
Shift Lock, and Hacker's Keyboard currently works the same way and just 
uppercases letters. You're asking for nonstandard behavior if you expect Shift 
Lock - I agree that this is a valid feature request, but it's still different 
from the way that physical keyboards behave.

How do you type strings such as "${1#+*#}" on a physical keyboard? I'd 
typically just hold down the Shift key while typing it, and you can do the same 
thing now in Hacker's Keyboard.

Original comment by Klaus.We...@gmail.com on 19 Jun 2012 at 12:21

[GoogleCodeExporter]

It is true. I can hold down the shift key while typing punctuation characters 
or upper case letters. But that would involve two hands/fingers doing it 
together, or I have to switch the shift key once for every special characters. 
Both ways are awkward to do on a small device. So in this case I guess most 
users, me included, would rather turn on the caps lock for the whole word, 
instead of shift lock for each letter. I know this is kind of nonstandard, but 
I guess it pays to make an exception from the accessibility point of view.

Original comment by jerryfle...@gmail.com on 19 Jun 2012 at 1:36

[GoogleCodeExporter]

Please try v1.34rc5 (or later) from 
https://code.google.com/p/hackerskeyboard/downloads/list and let me know if 
this works for you.

It now offers a choice of Shift Lock or Caps Lock. While locked, you can use 
multitouch shift to get the alternate caps/shift characters, for example to get 
digits in shift lock mode or 5th row punctuation in caps lock mode.

For Shift Lock, there's an additional option to control how it interacts with 
special keys. By default, Shift Lock only applies to regular keys (alphanumeric 
and punctuation), but it may be useful in some cases to enable it for all keys, 
for example shift-arrow selection on non-multitouch devices.

Original comment by Klaus.We...@gmail.com on 6 Jul 2012 at 1:30

• Changed state: Duplicate

[GoogleCodeExporter]

Yes. The Shift Lock does lock the 5th row now. Thanks.

Original comment by jerryfle...@gmail.com on 6 Jul 2012 at 1:39