Implement a common manager for composing input methods

Many input methods requires multiple inputs to compose a character, for example, Telex for Vietnamese (#183), Indic scripts (#368) or Korean (#305). Therefore, it could be helpful to have a common manager for them that reads from a config file. Each row in the config file represent a transformation rule, with the LHS being the sequence of keys pressed and the RHS is the output character.

For example, config for Telex can look like:

{
  "_depth": 2,
  "aa": "â",
  "as": "á",
  "âs": "ấ",
  "..."
}

I suppose we can use getTextBeforeCursor and setComposingText to implement this. Here is a pseudocode of how I think I would implement it:

fun onKeyPressed(pressedKey: Char, config: Json) {
    depth = config["_depth"]
    pattern = getTextBeforeCursor(depth - 1) + pressedKey
    if pattern is a key in config {
        replacedText = composingText.replace(pattern, config[pattern])
        setComposingText(replacedText)
    }
}

[Hayleia]

Teaser n°2… https://user-images.githubusercontent.com/7904776/117855172-8619c980-b28a-11eb-8af5-d563fbf94c05.mp4

More seriously once again, I got things to work I think? Note that the hiragana support in the video is incomplete and its only goal was to test the code that uses json rules.

Things that still need work:

• I haven’t touched the old regex thing, so there might be crashes for everyone who does not wipe the app’s data. But you said where that was so I’m guessing I can fix that.
• I probably forgot to update documentation comments at some places easy fix too.
• You said the composer should be right after the language tag. I did that in JSON but I didn’t do it in the add/edit subtype dialog. This wasn’t on purpose, I just copy-pasted the currency set dropdown and didn’t move anything. Should I put the composer dropdown right after the language dropdown (or elsewhere)?
• There is this line in commitText which calls that thing every time a character is typed, which might be a bad idea for performance. But I didn’t really know which object instances where renewed when switching layouts so I didn’t know where to save the composer value.
• Two “identical” subtypes can’t coexist but the “identical” part might need to be a little more permissive. For example people writing in japanese might want two identical layouts except one of them writes hiragana and the other one katakana? And in that case, there would be a need to display somewhere the difference between the two layouts? I have no idea.

[patrickgold]

Impressive work, really liking the direction this is going!

I probably forgot to update documentation comments at some places easy fix too.

That’s something what happens to me too, but in most cases this is something I fix after the core changes are in. Doc strings are important for other contributors to better understand what the code does, so it should be updated if possible.

You said the composer should be right after the language tag. I did that in JSON but I didn’t do it in the add/edit subtype dialog. This wasn’t on purpose, I just copy-pasted the currency set dropdown and didn’t move anything. Should I put the composer dropdown right after the language dropdown (or elsewhere)?

Yes it is best if the composer selection is right below the language dropdown in the Settings Dialog UI, like also in the JSON syntax.

There is this line in commitText which calls that thing every time a character is typed, which might be a bad idea for performance. But I didn’t really know which object instances where renewed when switching layouts so I didn’t know where to save the composer value.

This indeed looks a bit weird. For now let’s leave it in there, when your code base is fully ready we will see if we can improve on that specific line.

Two “identical” subtypes can’t coexist but the “identical” part might need to be a little more permissive.

Subtypes are only identical if a. the language, b. all the layouts, and c. the currency set matches

Meaning the same logic also applies for the composer once added to the subtype specification: one could have the same config for language/curr.set/layouts and as long as there are two different composers selected this shouldn’t cause any trouble. The list item summary string in the subtype list UI might need a rework to better reflect what each subtype represents, else it is of course a bit difficult to see the difference between the two.

Suggestions for this summary string:

• <character layout name> | <composer name> | <currency set name>
• <character layout name> | <composer name>
• <character layout name> | <currency set name>

What exactly fits best is a bit trial and error until something best matching has been found.