Skip to content

feat(web): browser-KMW support for default subkeys#9496

Merged
jahorton merged 7 commits intomasterfrom
feat/web/default-subkeys-9430
Sep 29, 2023
Merged

feat(web): browser-KMW support for default subkeys#9496
jahorton merged 7 commits intomasterfrom
feat/web/default-subkeys-9430

Conversation

@jahorton
Copy link
Copy Markdown
Contributor

@jahorton jahorton commented Aug 21, 2023

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.

  1. 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)."

  2. Longpress the d key.

  3. When the subkey menu is displayed, verify that the fifth subkey - "default" - is selected. The text may be cropped.

    image

  4. Without moving the touchpoint/finger, release the touchpoint / lift your finger. This should output the text default.

    • Note: if significant movement occurs, the text will not be output. (A small "fudge factor" is allowed before this occurs.)

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.

  1. 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)."

  2. Longpress the a key.

  3. When the subkey menu is displayed, verify that the third subkey - "a" - is selected.

  4. 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.

  1. Using Safari, download and then install the default-subkey keyboard package: default_subkey.kmp

  2. Within the iOS app, longpress the d key.

  3. When the subkey menu is displayed, verify that the fifth subkey - "default" - is selected. The text may be cropped.

    image

  4. Without moving the touchpoint/finger, release the touchpoint / lift your finger. This should output the text default.

    • Note: if significant movement occurs, the text will not be output. (A small "fudge factor" is allowed before this occurs.)

@keymanapp-test-bot
Copy link
Copy Markdown

keymanapp-test-bot bot commented Aug 21, 2023

User Test Results

Test specification and instructions

  • TEST_SPECIAL_DEFAULT (PASSED): Tested with the given testing page in a desktop browser and here is my observation: 1. Longpress the d key and verified that the fifth subkey -"default" - is selected. And the text was cropped. 2. Without moving the touchpoint, I released the touchpoint and verified that the text 'default' appeared on the screen. Seems to be working fine. (notes)
  • TEST_MATCHING_ID_DEFAULT (PASSED): Tested with the given testing page in a desktop browser and here is my observation: 1. Longpress the 'a' key and verified that the third subkey 'a' - is selected. 2. Without moving the touchpoint, I released the touchpoint and verified that the text 'a' appeared on the screen. Seems to be working fine. (notes)
  • TEST_IOS_SPECIAL_DEFAULT (PASSED): Tested with the attached PR build (Keyman 17.0.181-alpha-test-9496) in iPhone 13 Pro Max / iOS 15.0 Simulator and here is my observation: 1. Installed the default_subkey.kmp file in the Keyman In-App. 2. Long press the d key. 2. Able to see that the 5th key appeared in blue color with the name 'default'. The 'default' name is cropped. 3. Release the button and verified that the name 'default' appeared in the input text screen. (notes)

Test Artifacts

@keymanapp-test-bot keymanapp-test-bot bot added user-test-required User tests have not been completed and removed user-test-missing User tests have not yet been defined for the PR labels Aug 21, 2023
"pad"?: string | number,
"sk"?: LayoutKey[]
"default"?: boolean
}
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

function oskCreatePopup(obj,x,y) {
if(obj != null) {
var i;
var s = '';
var shift = false;
var keyPos = x.toString() + ',' + y.toString();
for(i=0; i<obj.length; i++)
{
// elementID contains the layer and coreID
s=s+obj[i].elementID;
if(obj[i].sp == 1 || obj[i].sp == 2) shift = true;
if(typeof(obj[i].text) != 'undefined' && obj[i].text != null && obj[i].text != '') s=s+':'+toHex(obj[i].text);
if(i < (obj.length -1)) s=s+';'
}
fragmentToggle=(fragmentToggle+1) % 100;
var hash = 'showMore-' + fragmentToggle + '+keyPos=' + keyPos + '+keys=' + s;
if(shift) {
hash = hash + '+font=' + 'SpecialOSK';
}
window.location.hash = hash;
}
}

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].)

@jahorton jahorton marked this pull request as ready for review August 21, 2023 05:33
kmw.init({
attachType:'auto'
}).then(function() {
kmw.addKeyboards({id:'default_subkey',name:'English',languages:{id:'en',name:'English'}, filename:'./default_subkey.js'});
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

@jahorton jahorton Aug 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is default just needed for ActiveKey? (wondering if LayoutKey and OSKKeySpec need it)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

export class ActiveKey implements LayoutKey {

export class OSKKeySpec implements LayoutKey {

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.

Copy link
Copy Markdown
Contributor

@darcywong00 darcywong00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm
Hopefully the browserstack fail is a flaky timeout?

@jahorton
Copy link
Copy Markdown
Contributor Author

jahorton commented Aug 23, 2023

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?

Copy link
Copy Markdown
Member

@mcdurdin mcdurdin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also LGTM. When the full gestures suite lands, it would be fantastic to have a demo of all the new functionality 😁

@mcdurdin mcdurdin modified the milestones: A17S21, A17S22 Sep 15, 2023
@mcdurdin mcdurdin added the m:osk On Screen Keyboard or Touch Keyboard, all platforms label Sep 16, 2023
@bharanidharanj
Copy link
Copy Markdown

  • TEST_IOS_SPECIAL_DEFAULT (PASSED): Tested with the attached PR build (Keyman 17.0.181-alpha-test-9496) in iPhone 13 Pro Max / iOS 15.0 Simulator and here is my observation: 1. Installed the default_subkey.kmp file in the Keyman In-App. 2. Long press the d key. 2. Able to see that the 5th key appeared in blue color with the name 'default'. The 'default' name is cropped. 3. Release the button and verified that the name 'default' appeared in the input text screen.

..long press d key

..After releasing the d key the name default is displayed on the screen

@bharanidharanj
Copy link
Copy Markdown

  • TEST_SPECIAL_DEFAULT (PASSED): Tested with the given testing page in a desktop browser and here is my observation: 1. Longpress the d key and verified that the fifth subkey -"default" - is selected. And the text was cropped. 2. Without moving the touchpoint, I released the touchpoint and verified that the text 'default' appeared on the screen. Seems to be working fine.

@bharanidharanj
Copy link
Copy Markdown

Test Results

  • TEST_MATCHING_ID_DEFAULT (PASSED): Tested with the given testing page in a desktop browser and here is my observation: 1. Longpress the 'a' key and verified that the third subkey 'a' - is selected. 2. Without moving the touchpoint, I released the touchpoint and verified that the text 'a' appeared on the screen. Seems to be working fine.

@keymanapp-test-bot keymanapp-test-bot bot removed the user-test-required User tests have not been completed label Sep 28, 2023
@jahorton jahorton merged commit 4a4c759 into master Sep 29, 2023
@jahorton jahorton deleted the feat/web/default-subkeys-9430 branch September 29, 2023 08:46
@keyman-server
Copy link
Copy Markdown
Collaborator

Changes in this pull request will be available for download in Keyman version 17.0.183-alpha

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants