feat: new sil_ipa gestures (first draft)

[jahorton]

A public link for anyone wanting to try out this draft: https://jahorton.github.io/sil_ipa.kmp

General rules of thumb:

• <key> + < => left flick (includes shifted versions)

• <key> + > => right flick (includes shifted versions)

• <key> + = => down flick (includes shifted versions)

• the superscript version of a default-layer key: up flick

  • exception to the above rules: the default-layer qs variants are based on ? instead, supporting glottal stops and similar characters.
  • There does exist a corresponding character for q now, if we'd rather fix the exception for superscript q: https://www.fileformat.info/info/unicode/char/107a5/index.htm
    • Added in Unicode 14.0 / 2021, so I understand why it wasn't originally part of the keyboard. I'll leave the glottal stop in place for now, though.
  • SHIFT+Q flicks are based on Q as per the standard pattern, though.

• !-based clicks: accessible as flicks on SHIFT+P following the patterns set above, with ! as up flick.

  • The p + = flick is still rooted on the default layer p per the rules above.

• the velarized/darkened version of a consonant: shift layer's up flick (if not otherwise defined)

  • except for special cases for particularly important superscript characters, such as the uvularization marker.

• if a | variant for a key exists and the shifted key's up-flick is still otherwise undefined, I used that instead of leaving the spot empty.

  • (this is probably my most questionable decision here)

• adds hints for some less-obvious subkeys (such as glottal stops being on the q)

  

The 'clicks' are all available from p (down) and shift+p (with hardware-keyboard's ! base as shift+p up-flick). The glottal-stop variants are all available from q and shift+q.

Aside from that, the patterns involved should be quite consistent, though there is some regrettable conflict between velarization and a few of the super-script variants.

[mcdurdin]

Note: this should not be merged until 17.0 is released.

[jahorton]

@mhosken @LornaSIL

No rush here; this is partly a fun thought experiment. That said, it may make a good keyboard to use as an example for flick-gesture use, and it would be nice to have a couple of early examples to point people toward when talking about the new gestures landing in Keyman 17.0.

So yeah, I thought I'd try adding gesture support to the IPA keyboard - it seems like it could be a fantastic case for use of the new flick gesture type. Since there do seem to be just four "main modifiers" (<, >, =, ^) with very consistent patterns, it seems like the patterns should be easy to "mentally map" to the four flick directions. This way, users can use the desktop patterns they already know without having to learn new patterns.

~, for velarization, gets treated as a fifth on the shift layer, as the keyboard hasn't done superscript capitals per key. As noted above, I did, early on, also consider some use of | outputs, but in retrospect, the few uses that remain in the version seen here are probably better to drop - those are generally non-IPA characters, anyway.

You two are far more "expert" in this field... and are listed as the original authors for the keyboard... so I feel I should leave the ball in your court on this. Feel free to reject this idea or to modify things to better suit what you believe would be most needed for end users.

[darcywong00]

Noting that subscript numerals are getting added in #2587 . It might be nice on the numeric layer to also add those (convert superscript and subscript numerals to flicks?)

[LornaSIL]

Mostly I like it. The flicks on the uppercase layer are kind of irritating because when I was trying different flicks on SHIFT it kept reverting to the default layer rather than staying with SHIFT. Maybe I wasn't typing it correctly.

I'm wondering about the keyboard automatically going to default anyway since this is IPA does it make sense to default back to the default layer? I know you didn't make that change and I cannot remember at what point we added that (It looks like it's been that way since I created the mobile layout. Since no one has complained maybe that's not an issue.)