nextlayer processing in KeymanWeb is not working correctly about keyman HOT 7 CLOSED

See also #54 for extra notes

from keyman.

Hi @mcdurdin , this issue is not just KMWeb, it is also a major bug in touch keyboards. As 90% of my keys need a "nextlayer" to default...I'm having to add line after line of non-elegant code to make the desktop KB compatible with KMW and Touch (this is currently in addition to needing to add a platform comment to every line of code with a RALT, CAPS or NCAPS)

https://github.com/erros84/keyboards/blob/master/cameroon_qwerty/source/cameroon_qwerty.kmn.

+ [T_003B] > U+003B layer('default')
+ [T_003F] > U+003F layer('default')
+ [T_0021] > U+0021 layer('default')
+ [T_00A1] > U+00A1 layer('default')
+ [T_2039] > U+2039 layer('default')
+ [T_203A] > U+203A layer('default')

and

platform('web') + [K_U] > U+0075
platform('web') + [SHIFT K_U] > U+0055
platform('desktop native') + [NCAPS K_U] > U+0075
platform('desktop native') + [CAPS K_U] > U+0055
platform('desktop native') + [NCAPS SHIFT K_U] > U+0055
platform('desktop native') + [CAPS SHIFT K_U] > U+0075
platform('desktop native') + [NCAPS RALT K_U] > U+0289
platform('desktop native') + [CAPS SHIFT RALT K_U] > U+0289
platform('desktop native') + [NCAPS SHIFT RALT K_U] > U+0244

from keyman.

@erros84 KeymanWeb is the engine within both Keyman for Android and Keyman for iPhone and iPad.

You may find that restructuring your keyboard with store statements helps to make it easier to read, e.g.

story(touch-key) [T_003B] [T_003F] [T_0021] [T_00A1] [T_2039] [T_203A]
store(touch-out)  U+003B   U+003F   U+0021   U+00A1   U+2039   U+203A

+ any(touch-key) > index(touch-out, 1) layer('default')

from keyman.

It may be worth noting that we are looking at ways of improving how nextlayer works because there's a whole lot of detail about when the keyboard should switch back to the default layer and when it shouldn't; for example when pressing most punctuation it is sensible to swap back to base layer, but when pressing a digit it isn't; spacebar on some devices switches back to base layer but this is also often problematic. Any thoughts you have in that direction as to how we can genericise nextlayer or make its use less verbose appreciated.

from keyman.

Rather than making nextlayer automagically work in certain situations, please leave it up to the keyboard developer.
First priority IMO would be to get KM to respond (after outputting the character) to whatever you configure for nextlayer in the Developer. If you can get it so that the character is output BEFORE triggering nextlayer (if chosen), that's far enough for me. This will allow the developer to precisely control it from the KMDeveloper interface.

Use cases in my situation:

• When shifted, pressing a letter writes the letter and returns to default.
• When showing "special characters", pressing a letter writes the letter and returns to default.
• Pressing a diacritic writes the diacritic and returns to default.
• Pressing some punctuation "!?[« etc returns from the number/symbol page to default BUT not .,() and some others that are often used when typing numbers.

from keyman.

Thank you for the feedback. We're not planning on making things work 'automagically' -- the design would always be up to the keyboard developer. But we can design common rules that a keyboard developer can choose to employ in their keyboard, thus simplifying their keyboard rules and reducing the time required to create the keyboard layout.

We are planning to fix nextlayer in the next sprint -- but this work will be done for the next major release of Keyman, which will be a bit further off.

from keyman.

Fixed by #310

from keyman.