Dear Keyman Developer community,
I’m in the process of creating a keyboard for use in a dictionary built with the Dictionary Builder App.
I want to create a keyboard that has a long press level on the vowel U+10D1D to be able to type the combination U+10D1D + U+10D25 (vowel a-for with a Tahala sign on top).
I’d like to have this as a single key stroke (on a long press) instead of needing to type a-for first and then Tahala [I want to save screen space on the keyboard as it has 4 different levels for the three Rohingya scripts included in the dictionary and the numerics.]
I think the first step is building your keyboard with Keyman Developer. Here’s a sample adding those items to the “q” key (though the characters don’t show up because I don’t have the right font):
I selected the U+10D1D character from the keyboard map at the right (after specifying the character in the filter field at the bottom of that pane) and dragged it to the “q” key (after deleting the existing “q” character). I then changed the “ID” field to U_10D1D so that this key will generate U+10D1D. Clicking on the “Add longpress group” button brings up a new key at the bottom of that pane.
The new longpress key is given the ID “T_new_103” (though the exact name may be different in your case). You have two options: (1) you can change the ID to “T_10D1D_10D25” and include a rule in the .kmn file to change
+ [T_10D1D_10D25] > U+10D1D U+10D25
Or (2) if you are using Keyman Developer version 15 (currently only available as a beta test version) you can change the ID to “U_10D1D_10D25” and the two characters will be output. If you do this, you must add one line to the beginning of .kmn file:
to let the compiler know that you are using this feature of Keyman version 15.
To get the characters on the longpress key, I dragged the U+10D1D to the key, then filtered for U+10D25 and dragged that key next to it. (Since you know the script, you may find it easier to just filter for that block and pick the right character by sight.)
In the end this looks something like:
(though the characters are square boxes since I don’t have the correct font).
But if this doesn’t answer your question, please write again.
@Marc If I use the U_xxxx_yyyy form (and remember to include
store(&VERSION) '15.0' in the .kmn file!), does that mean that the user of the keyboard has to be running Keyman v15? that is, that the keyboard won’t work on a phone running an earlier version of Keyman?
And how does that relate to Keyman App Builder? Does KAB have to pick the right version of the Keyman engine?
Would Michael be better off sticking with an ID of
T_10D1D_10D25 coupled with a rule in the .kmn file?
As is the case with any new feature, it can take time for the distribution of the platform to catch up. Early adopters can suffer a little!
So, correct, the
U_xxxx_yyyy form does require Keyman 15 to work. It won’t work with earlier versions. AFAIK, KAB does not currently integrate Keyman Engine 15 so I would recommend using the
T_xxxx_yyyy form until Keyman 15 is released (next month) and KAB is updated (no idea on timeline).
Dear David, dear Marc,
Thank you very much, this is exactly the answer I need.