Longpress touch confusion

I’m new to Keyman developer and am trying to understand how to write a rule for a longpress virtual key. In my case I need each individual longpress to enter multiple diacritics (such as c+caroncomb+commabovecomb). I have seen that there is a workaround where the ID: is named “T_030C_0313” and then the rule is + [T_030C_0313] > U+0063 U+030C U+0313 (I hope I’ve gotten all the unicode right). However I don’t understand where to enter the rule so the keyboard will compile. The posts say to add it to the .kmn file, but I"m unsure when to do this. I assumed there would be some sort of interface element in the keyboard design to enter this, but the ‘code’ tab doesn’t seem to be the place.
Any advice is appreciated.

The ‘code’ tab would indeed be the place. You’d want to add it after the group(main) statement, assuming your ‘code’ section only has one such group statement. In case this reference might be helpful: Keyman language overview

Alternatively, you can also change the T to U in the keyboard touch layout designer; this will imply the rule without having to write it. Note that U_030C_0313 would only output U+030C followed by U+0313, as those are the two codepoints specified by the hypothetical key ID. If you wanted c as well, you’d want U_0063_030C_0313, as U+0063 = c. A reference for this case: Keys, Virtual Keys and Virtual Character Keys

Joshua,
Thanks for the feedback. I think the second option may be more maintainable for my purposes, but I don’t quite understand your instructions. In my case, I have multiple long presses set up for all of the instances of the base character, for instance (with the normal. ‘c’ character):
default key: c
longpress 1: c+commaabovecomb
longpress 2: c+caroncomb
longpress 3: c+caroncomb+commaabovecomb

I don’t understand your instruction “If you wanted ‘c’ as well”. I understand “ou’d want U_0063_030C_0313”, and I don’t understand what to do with “as U+0063 = c”.

I read Keys, Virtual Keys and Virtual Character Keys, but it didn’t clarify for me.

2023-01-12_20-10-48

Regards,

Jim

1 Like

Thanks for your excellent screen capture. Change the ID field for the three longpress keys:

T_new_912 to U_0063_0313
T_new_914 to U_0063_030C
T_new_915 to U_0063_030C_0313

You then don’t need any rules in the .kmn file.

1 Like

drowe, thanks for the instructions. I tried that earlier and received this compile error:


Somewhere in a forum post I read something about a version 15 error, but I’m unable to find it now. I think the post said you need to edit script and specifically state V15, or something like that.
I’m using KM 15.0.274.0
Regards,

This line in your .kmn file needs to be 15.0. In general when you create a new keyboard I believe it assigns it a minimum version of 10.0

store(&VERSION) '15.0'
1 Like

Lorna,
Thanks for the hint, that worked!
Regards,

This is wonderful to know. Thank you very much. It took me quite a while to find this information in order to figure out how to do this though.

May I please suggest that each longpress key’s ID field be the equivalent to its Unicode value by default? That would save everyone a lot of time changing the numbers to encode these things.

When a new longpress key is added to the keyboard, a T_new_xxx label is created for the key. At the moment of creation, Developer doesn’t know what character(s) or other actions will be assigned to the key, nor whether additional logic will be needed in the .kmn file, so it can’t really know what U_xxxx label might be needed.

Perhaps there could be an option for keys on the touch layout that would change the label to match the content. @marc Any thoughts?

2 Likes

Yes, this would be a nice feature to be able to do this automatically in the layout builder. I’m not sure when this would be added but it’s possible we could squeeze it in to v17.0 if it ends up being straightforward to implement. I’ve listed it in an upcoming sprint, and if we have time, we’ll give it a go: feat(developer): infer key id automatically from key cap in touch layout editor · Issue #9433 · keymanapp/keyman · GitHub

2 Likes

This topic was automatically closed after 14 days. New replies are no longer allowed.