feat(web): browser-KMW support for default subkeys#9496
Conversation
User Test ResultsTest specification and instructions
Test Artifacts
|
| "pad"?: string | number, | ||
| "sk"?: LayoutKey[] | ||
| "default"?: boolean | ||
| } |
There was a problem hiding this comment.
For Android: this (mixed with ActiveKey, seen in the file above) is the type of the subkeys provided by Web to the oskCreatePopup function found in the keyboard-host page:
keyman/android/KMEA/app/src/main/assets/android-host.js
Lines 261 to 282 in 8ba1989
The obj parameter is an array of these objects. Currently, oskCreatePopup only references elementID (from ActiveKey) and text - so we'll need something to annotate a 'default' key when calling out from KMW into Android code.
(elementID is a mix of the layer ID for the layer hosting the base key, the key's ID [id], and the layer ID to use for any relevant key modifiers [layer].)
| kmw.init({ | ||
| attachType:'auto' | ||
| }).then(function() { | ||
| kmw.addKeyboards({id:'default_subkey',name:'English',languages:{id:'en',name:'English'}, filename:'./default_subkey.js'}); |
There was a problem hiding this comment.
Did you manually move ./build/default_subkey.js to this folder?
I see the .kpj and .kps compile to ./build/default_subkey.js so I wonder if the test page should just use that
There was a problem hiding this comment.
I did. Keep in mind, our .gitignore settings omit anything within build folders; that's why I copied it.
I guess I could mark it as an exception in a local .gitignore?
| "nextlayer"?: string, | ||
| "pad"?: string | number, | ||
| "sk"?: LayoutKey[] | ||
| "default"?: boolean |
There was a problem hiding this comment.
Is default just needed for ActiveKey? (wondering if LayoutKey and OSKKeySpec need it)
There was a problem hiding this comment.
When loaded, the touch-layout spec within a keyboard is generally an instance of type LayoutKey with all the properties and methods of ActiveKey copy-pasted onto it.
As for OSKKeySpec, after checking, it appears to only ever be constructed when a default is needed. Otherwise, the LayoutKey is typecast to OSKKeySpec, and it works.
darcywong00
left a comment
There was a problem hiding this comment.
lgtm
Hopefully the browserstack fail is a flaky timeout?
|
For the LMLayer tests: the macOS-Monterrey configuration failed to connect properly. That's all. For the Web ones, it seems like the Android ones are the ones failing to connect properly. That's actually kind of concerning, since this PR's changes are most focused in that direction... but a local run of the automated tests passes flawlessly under Chrome's remote device emulation. And it's not unheard of for there to be stability issues with the Android target for our BrowserStack runs. ... except the latest Web run? Android ran fine. It was macOS-Monterrey. Sounds like BrowserStack may just be having a bad day/week? |
mcdurdin
left a comment
There was a problem hiding this comment.
Also LGTM. When the full gestures suite lands, it would be fantastic to have a demo of all the new functionality 😁
|
Changes in this pull request will be available for download in Keyman version 17.0.183-alpha |




Building on the work from #9432, this adds support for default subkeys to KMW (and to the iOS app).
See also #9416.
The Android version of Keyman will require extra handling due to how it has special subkey handling of its own.
Note: most of the new changes are for the new manual testing page and its keyboard - I don't know of an existing keyboard resource with default subkeys yet, so I drafted one from scratch.
User Testing
TEST_SPECIAL_DEFAULT: if a subkey exists with an explicitly-marked 'default' subkey, it should be auto-selected when the subkey menu is first displayed.
On a mobile device (or when emulating one in a desktop browser), visit the testing page marked "Tests handling of new default-subkey feature (feat(developer): define long-press default key 🐵 #9430)."
Longpress the
dkey.When the subkey menu is displayed, verify that the fifth subkey - "default" - is selected. The text may be cropped.
Without moving the touchpoint/finger, release the touchpoint / lift your finger. This should output the text
default.TEST_MATCHING_ID_DEFAULT: if a subkey exists with an ID perfectly matching its base key, it should be auto-selected in the absence of a specified subkey.
On a mobile device (or when emulating one in a desktop browser), visit the testing page marked "Tests handling of new default-subkey feature (feat(developer): define long-press default key 🐵 #9430)."
Longpress the
akey.When the subkey menu is displayed, verify that the third subkey - "a" - is selected.
Without moving the touchpoint/finger, release the touchpoint / lift your finger. This should output the text
a.TEST_IOS_SPECIAL_DEFAULT: the same as the first test above, but this time within the iOS app.
Using Safari, download and then install the
default-subkeykeyboard package: default_subkey.kmpWithin the iOS app, longpress the
dkey.When the subkey menu is displayed, verify that the fifth subkey - "default" - is selected. The text may be cropped.
Without moving the touchpoint/finger, release the touchpoint / lift your finger. This should output the text
default.