I imported it and it compiled. But, when I looked at the code, I didn’t see the other multi-key stroke rules – just the “default” keys (etc…) for the most part. I didn’t test it out yet though to see if it will generate the desired output when I type those keys on the phone.
I was reluctant to try importing because of something in the past (I can’t remember exactly what it was now). So, I was accustomed to just going into the phone code and editing it.
The rules are already in the .kmn file and the touch-layout picks those up. It is only when you want to modify the behavior of the touch-layout (such as adding long-press keys) that you really need to make changes.
A really nice thing that was recently added (to Keyman Developer 15) was the ability to test the keyboard on the web. You can go to the Build tab and compile, then click on Test Keyboard on web, click on a link and click on Open in Browser. Select your keyboard, and a device and then you can test it that way. You don’t have to install the keyboard for testing. That has saved me a lot of grief.
Now I have to figure out how to get the SHIFT key to work (I remember that being an issue before) and prevent certain of the kvks keys from acting like kmx.
Also, some of my long-press keys aren’t generating certain characters either although I see all the long-press characters are visibly there. Some of them work and some don’t.
I remember one of the videos describing how to edit the code specifically for phones (so I intend to review that/those shortly).
In previous versions of Keyman, it didn’t always set the SHIFT key properly. The current version does, but if you started on this keyboard before, it might not. Make sure when you have the Shift key selected (on touch layout), that Next Layer: is set to “shift” as in this screenshot:
For longpress keys you can use the same keycode as would work for the .kmn, or you can use the U_xxxx syntax. In this example, the first longpress uses U_00AB, the 2nd one has the layer set to “shift” and the ID would be K_COMMA, the 3rd one has the layer set to “shift” and the ID is K_LBRKT. The 2nd and 3rd ones would output exactly what your .kmn outputs for SHIFT COMMA or SHIFT LBRKT. Sometimes people forget to change the layer from default to shift and that may be where you are having problems with the wrong output.
The long-press (and certain other) characters that were still acting like like the lap-/desktop, I changed them from “T_new_xxxx” to “U_xxxx” and the worked!
The SHIFT is shifting to that state, but not back to the default. But, when I hit the control key, it returns. I can deal with that personally for now, lol. But, not for distribution. Would you happen to know how I can address that too?
You might want to select the Next Layer for the Shift key on the Shift layer. When clicking on the dropdown menu, you should see all available layers (see the screenshot below). Pick the default for the key for it to switch back to Default layer when triggered.
In one of my keyboards (phone), I’m noticing that the characters continue to change even after I’ve used “dk + space + space” which should produce a space. But, it works just fine on the lap-/desktop.
Anyone here have any pointers for that?
It doesn’t appear to be that big of a deal though since I do see that “shift + space” does produce a space without the characters continuing to change from what I’ve noticed so far. I’ll continue testing though.
Does the dk being referred to existing in the touch layout? If the key for the character being referred to as a deadkey doesn’t exist. Probably have been defined differently on touch layout, i.e. using Unicode code point “U_xxxx” instead of “K_x”. You can drop the keyboard project folder in DM for me to try and check it out.
