How to write multi-key sequence output (with dead key) in JSON for Android phone

Keyman Keyman How To
1

Hello!

I know how to produce the following for desk-/laptops for multi-key strokes for one output and dead key:
“ABC” + [K_SPACE] > ‘D’
“˙” + [K_SPACE] > dk(quote)

But, I haven’t yet figured it out for this language/syntax so that it’s available for phones, etc… as well:
{
“id”: ,
“key”: [
{
“id”: "",
“text”: “___”
}
]
}

I’ve tried out a few things that haven’t worked so far. I’m sure it’s because I’m not aware of some identifier or something like that if that’s suspicion is even correct.

So, could someone please help me out with this?

Thanks, again in advance.

2

Touch keyboards are visually oriented, so the use of dead keys is much less common.

There are some videos (made during a 2020 workshop) covering keyboard development available at:
https://help.keyman.com/developer/videos/
You might want to look at the one on Touch Screen Keyboard Design (Keyman Developers Workshop 2020 - Touch Screen Keyboard Design on Vimeo)

What are you using the dead key for? Suppose it’s for an acute accent. Maybe you want a separate key on the touch layout that has an acute accent on it, so users have a clue about what it is for, that puts an acute accent on the preceding character.

If that doesn’t give you the information that you need, please write again!

1 Like
3

Thanks for the links!

I’ve seen them before (they’re pretty good) and watched one of them within recent hours while trying to work on this project too, but I don’t think it was this one (which I remember from some months ago by the way though).

I want to use K_SPACE to be able to change between multiple characters and then the dk so that K_SPACE functions as a space key again.

Thanks again!

4

Like drowe, I would be wary about using multi-key output rules in a touch screen layout, and seek to use longpress characters instead.

But I have had some experience with multi-key output rules in a touch layout. And I think the example rules you have in the KMN file would work on your touch layout just like on your desktop layout. In your example, I think if you press ABC then press Space on the phone, you’ll get D, even without putting that rule in the code section of the touch layout keyboard. Have you tested your touchscreen keyboard? Perhaps it is working already?

1 Like
5

Thanks.

I’ll try that out. It’s just that the code already in the touch layout looks different than in the lap-/desktop layout, so I didn’t really think that would work.

No, I haven’t tested it yet because the code editor alerts me ahead of time with red marks letting me know that it won’t compile.

After seeing something on a Keyman page and in the video link that Drowe shared, I was thinking about testing out something like:

  • [T_ …] > ‘__’

I don’t know thought. I intend to be playing around with it for a little bit and looking around some more. I’m sure I’m possibly overlooking something.

I also remember it not being recommended to have more than 8 long-press keys in one of the videos which makes sense. So, I wanted to to use some outputs from multi-key strokes (plus “K_SPACE”) along with a dead key (this latter I may add to a long-press key though, but I’d still like to know how to enter it like in my initial question just in case I change my mind because I do like how it works already on my lap-/desktop keyboards).

Thanks again!

6

You can use [T_xxxx_xxxx] in the touch layout, but then you need to write a rule that is in your .kmn file that tells it what to do.
Or, in Keyman Developer 15.0 you can use [U_xxxx_xxxx] and it will know to output whatever two codepoints are there (in place of xxxx).

1 Like
7

Okay, great! Thanks! The first one with the “T_” prefix looks like what I read and saw in a video. I’ll test it out.

Thanks again!

8

Good morning!

Hope you and others here are enjoying the weekend.

I probably should’ve included in my initial inquiry that I’m not very knowledgeable in code writing but have had success editing codes for certain keyboards (more “complicated” ones for lap-/desktops and also more simple ones for phones) in recent years.

So, I wanted to ask if I should put some kind of “id”: “___”, before the set of rules [U_xxxx_xxxx]?

If so, what should I put in the blank “id” space?

And should it be written as:
{
“id”: “",
[U_xxxx_xxxx_xxxx] >
“text”: “U_xxxx”
},
{
“id”: "”,
[U_xxxx_xxxx_xxxx] >
“text”: “U_xxxx”
},
…?

Do I need to add + before the rule like +[U_xxxx_xxxx_xxxx]?

Again, no rush. It’s the weekend.

Thanks again, in advance!

9

If you use U_xxxx_yyyy as the id value (“id”: “U_xxxx_yyyy”), then the key will output U+xxxx U+yyyy when the user selects that key. The “text”: “z” will display “z” on the key. Normally the two (“z” and U+xxxx U+yyyy) are the same (or similar in appearance), but sometimes you want to display something in the text field (“ZWJ” for example) when inserting an invisible character.

1 Like
10

Thanks.

Essentially, an example of what I’m trying to make the Android keyboard function like is:

  1. when the user presses the “a” key followed by the “e” key and then the “SPACE” key, I want the output to be “æ”;

  2. and if the “SPACE” key is pressed again, for “æ” to change to “Æ”;

  3. and if “SPACE” key is pressed another time for “Æ” to return back to “æ”, etc…

4a) And to stop that cycle of “æ” changing to “Æ” when the “SPACE” key is pressed, I want to use the “dead key” for that purpose to cause the “SPACE” key to return back to making a space between words again.

4b) And I wanted to use the little “high dot” to signal that the “dead key” has been pressed and is about to generate an “invisible space” if followed by pressing the “SPACE” key.

That’s how my lap-/desktop keyboard functions, and I did it by writing rules comparable to:

  • [K_A] > ‘a’
  • [K_E] > ‘e’

“ae” + [K_SPACE] > ‘æ’
“æ” + [K_SPACE] > ‘Æ’
“Æ” + [K_SPACE] > ‘æ’

  • [K_COLON] > ‘˙’
    “˙” + [K_SPACE] > dk(quote)

Again, I really like how that works for lap-/desktops as it allows one to use several (hundreds of) letters, etc… I know how to add the long-press keys to the phone. I just don’t know how to write the “phone equivalents” to the rules like those just given to expand user access to even more keys.

If there’re any “peripheral tokens” I may need to know about, that would help as well.

Thanks again!

11

Have you actually tried the keyboard? I would think that if it works on desktop, it would work on the phone layout without special rules.

1 Like
12

Yes. And it indicated it was incorrect with red signals on the code itself along with saying in the Messages that there’s an “Error: 4059 Invalid JSON at offset 0” when I tried to compile it anyway.

13

I changed a “test rule” like:
“ae” + [K_SPACE] > ‘æ’

…to:
},
{
“id”: “a_e_K_SPACE",
“text”: “æ”
}

… and there was an improvement (in that it didn’t give red indicators of errors on the actual code itself). But, when I tried to compile it, it said there was an “Error:… Member row is required” and then “Member key is required” after I moved it one time, and then I moved it again and it said it “has an invalid identifier”.

Thus, the phone is requiring things like “member rows, member keys” and “identifiers” (etc…) that the lap-/desktop doesn’t require (making the latter easier to write).

And that’s what I thought was part of the problem initially: not knowing what labels to use for the multi-key stroke rules. " “id”: " didn’t seem correct to me, but I tried it anyway and the red-error indicators went away (which is a good thing, lol) although it’s still saying it “has an invalid identifier” like I said. I also suspect the rule following “id”: between the quotation marks and before the comma may be incorrect as well. But, I think the immediate issue at this time might be regarding what identifier to use for multi-key rules.

Thanks for that suggestion though. It was an improvement.

14

I’m just wondering, are you working with the raw JSON format .keyman-touch-layout instead of using the visual editor? The visual touch layout editor included with Keyman Developer makes it much easier to work with the files.

In terms of the touch layout files, there’s a fundamental concept here that I think is important to understand: the .keyman-touch-layout file describes the position of keys on a touch layout. It is not really about their behaviour.

Each key in a touch layout has an identifier that:

  1. maps to a hardware key on a physical keyboard (e.g. K_A), or
  2. maps to a Unicode value (e.g. U_1234), or
  3. is a custom touch layout identifier (e.g. T_A_ACUTE).

Each key you press on the touch layout will generate an event for the .kmn keyboard rules, so you can map K_A, T_A_ACUTE, or even U_1234 from the touch layout to a corresponding rule in the Keyman source file. So, given a .keyman-touch-layout snippet such as:

...
"row": [
  {
    "id": 1,
    "key": [
      { "id": "K_A", "text": "a" },
      { "id": "T_A_ACUTE", "text": "á" },
      { "id": "U_1234", "text": "\u1234" },
      ...
    ]
  },
...

You could have a set of corresponding rules in the .kmn file for transforming the output:

+ [K_A] > 'a'
+ [T_A_ACUTE] > 'á'
+ [U_1234] > U+2468    c possible, but not advisable, for illustration only!

These rules must be in the .kmn file, which then can share behaviour between desktop and touch layouts.

This means that all the flexibility of what you can achieve on the desktop with Keyman rules is equally available on touch devices. This includes working with context or multiple groups.

Note that some key identifiers do inherit “default” output if you don’t define rules for them. That includes the K_xxx identifiers – which emit the corresponding character if one exists, and any U_xxxx Unicode identifiers. T_xxxx identifiers never have any default behaviour.

More info:

1 Like
15

Thanks.

If I could just see an example of this:
image

… as multi-key strokes for one output (using K_SPACE to change between alternate letters like I’ve seen on Tigrinya and Ancient Egyptian keyboards for example):

https://help.keyman.com/keyboard/hieroglyphic/1.4/hieroglyphic

image
image895×293 35.1 KB

I know how to write the rules you shared with me as they still look like examples of how to write “sub-keys” rather than multi-key strokes for one output which this latter is what I’m trying to do.

Thanks again though.

16

The space would just be an ordinary key on the keyboard in the .keyman-touch-layout file:

...
"row": [
  {
    "id": 1,
    "key": [
      { "id": "K_SPACE", "text": " " },
      ...
    ]
  },
...

The behaviour of the spacebar is implemented in the .kmn file:

"ABC" + [K_SPACE] > "D"

Note that sub-keys (or longpress keys) are defined in the .keyman-touch-layout file, but again, each longpress key has an id that triggers a rule in the corresponding .kmn file.

1 Like
17

Thanks, Marc!

I’ll try that out!

18

A couple of thoughts:

  1. The Hieroglyphic Keyboard uses the spacebar to move between items in a rota and uses CTRL+SPACE to generate a normal space character (U+0020). This makes sense on that keyboard because rotating characters in a rota is common, probably more common than needing a space character typed.
  2. You are also using the spacebar to rotate through entries in a rota. And using a complex deadkey sequence to generate a space character. From your description I can’t tell if for your keyboard makes heavy use of rotas like the Hieroglyphic Keyboard, or whether needing to use rotas is rare. If it is rare I would not overload the spacebar, I would reverse the usage in Hieroglyphic Keyboard. I.e. use SHIFT+SPACE or CTRL+SPACE for the rota and use SPACE for the normal space.
  3. The touch keyboard layout and the physical keyboard layout do not need to work the same. I would be inclined to change how the touch keyboard works, two ideas come to mind:
    • Do not use rotas with the touch layout, move all characters in the rotas to a longpress on an appropriate key.
    • If you want to retain the rotas, rethink how you want them to work. I would be inclined to reduce the size of the spacebar and put a second identical key next to it, one key for rota and one for the space character.

Restressing:

The KMN file contains all the rules for the keyboard, both physical and touch. But the physical and touch keyboards do not have to work identically.

The layout should be intuitive and easy to use, no complex key sequences unless it’s unavoidable.

A touch layouts key arrangements don’t necessarily have to be identical to a physical keyboard arrangement.

1 Like
19

Thanks for that helpful information.

I don’t think I’ll be able to avoid using the spacebar for rota between characters. CTRL+SPACE sounds like a good/great idea though – more simple than “dead key”. I think I’ll do that too.

But, how would I write the code rule for using spacebar for rota between characters on a phone? What does that code rule look like for a phone? Is it supposed to be labeled with an “identifier” like “id”: or something else? Should it be on a certain layer?

20

If you just import the keyboard from the desktop layout, you shouldn’t need to make significant changes to the phone layout. The rules will work the same. However, if you want the space on the shift or ctrl layer to behave the same as the space on the default layer, you may need to change the space key on those layers, to be labeled “default” layer so that those rules will still behave properly. There shouldn’t be a need to edit the .json code. You should be able to use the visual editor. When you try to edit the .json code directly you are probably going to delete commas or end brackets, etc which mean it won’t compile.

1 Like