feat(web): implementation of modipress, integration with multitap 🐵 #9876

jahorton · 2023-10-27T06:55:14Z

Another goal from #5029: introducing the "modipress". (#5029 (comment) for the original mention.)

Short for "modi-fier long-press", this is a gesture interaction in which the user may hold down any of our recognized modifier keys to temporarily shift the keyboard's active layer... as if it were a longpress key. (Such behavior exists in iOS's default keyboard, for example.) Its layer will then be locked in place until the interaction ends, allowing the user to type with the keys of that layer. Lifting the finger holding the modifier key will then return to the original layer.

Bonus: this also works with layers reached through multitapping on such a key! Tapping once, then holding on a second tap will activate the layer corresponding to the first multitap key under the modifier key - the key that'd normally be reached by a second tap.

At present, this is locked by the following logic:

keyman/web/src/engine/osk/src/input/gestures/specsForLayout.ts

Lines 82 to 94 in facafe3

    
           function keySupportsModipress(key: KeyElement) { 
        
             // Future enhancement idea:  allow some extra way for a key to say "hi, I'm modipressable". 
        
             const keySpec = key.key.spec; 
        
             const modifierKeyIds = ['K_SHIFT', 'K_ALT', 'K_CTRL', 'K_NUMERALS', 'K_SYMBOLS', 'K_CURRENCIES']; 
        
             for(const modKeyId of modifierKeyIds) { 
        
               if(keySpec.id == modKeyId) { 
        
                 return true; 
        
               } 
        
             } 
        
             // Allows special-formatted keys with a next-layer property to be modipressable. 
        
             return keySpec.sp > 0 /* ButtonClasses.normal */ && keySpec.sp < 8 /* ButtonClasses.deadkey */ && !!keySpec.nextlayer; 
        
           }

The main thing: it's a lot simpler if we don't have to rely on key-event rule processing to determine whether or not a key should be considered for modipresses. If an approach can fit within the method posted above ("... the following logic"), it'll be very easy to integrate. We can even add access to the compiled keyboard object (say, for a "here's all keys for modipress" property) if needed.

As for the keys included above... including K_NUMERALS, in particular, gives us numeric-layer modipress for sil_euro_latin.

K_LOWER (the numeric-layer 'abc' key) is not currently included, but perhaps I should correct that. That said, the

Possibly relevant codes for consideration:

keyman/common/web/keyboard-processor/src/text/codes.ts

Lines 71 to 74 in 6aaf58a

    
           "K_LOPT":50001,"K_ROPT":50002, 
        
           "K_NUMERALS":50003,"K_SYMBOLS":50004,"K_CURRENCIES":50005, 
        
           "K_UPPER":50006,"K_LOWER":50007,"K_ALPHA":50008, 
        
           "K_SHIFTED":50009,"K_ALTGR":50010,

As for this part:

if(key.sp > 0 && key.sp != 8 && key.nextlayer) - if the key is marked for special styling that doesn't match deadkeys and has a nextlayer property, we'll trust that key "in good faith" as a modipressable layer-swap key.

Reference:

keyman/common/web/types/src/keyman-touch-layout/keyman-touch-layout-file.ts

Lines 67 to 89 in 6aaf58a

    
           export const enum TouchLayoutKeySp { 
        
             normal=0, 
        
             /** A 'frame' key, such as Shift or Enter, which is styled accordingly; uses 
        
              *  the 'KeymanwebOsk' font on KeymanWeb */ 
        
             special=1, 
        
             /** A 'frame' key, such as Shift or Enter, which is styled accordingly and is 
        
              *  highlighted to indicate it is active, such as the shift key on a shift 
        
              *  layer; uses the 'KeymanwebOsk' font on KeymanWeb */ 
        
             specialActive=2, 
        
             /** **KeymanWeb runtime private use:** a variant of `special` with the 
        
              *  keyboard font rather than 'KeymanwebOsk' font */ 
        
             customSpecial=3, 
        
             /** **KeymanWeb runtime private use:** a  variant of `specialActive` with the 
        
              *  keyboard font rather than 'KeymanwebOsk' font. */ 
        
             customSpecialActive=4, 
        
             /** A styling signal to indicate that the key may have 'deadkey' type 
        
              *  behaviour. */ 
        
             deadkey=8, 
        
             /** A key which is rendered as a blank keycap, blocks any interaction */ 
        
             blank=9, 
        
             /** Renders the key only as a gap or spacer, blocks any interaction */ 
        
             spacer=10 
        
           };

(The version directly above has not yet reached this branch, though.)

It'd be a "heuristic" of sorts, though - there's nothing stopping someone from special-styling a text-output key that would swap the layer too. Hopefully folks don't consider that a "feature" and instead wisely design their layouts accordingly.

One extra-fun interaction:

If a subkey menu has been opened during a modipress and the modipress key is lifted, subkeys still work... but any nextlayer attribute on the subkeys will not take effect, as it's from a subkey of the modipressed layer.

While we could "just" cancel the subkey-menu operation... I think this scenario is both niche enough and consistent enough to be reasonable. I think it could be possible to maintain the layer-lock until the modipressed longpress is complete, but that will take extra effort to accomplish.

User Testing

TEST_BASIC_SIMPLE_SHIFT: Using the standard "Test unminified KeymanWeb" test page from a mobile device...

Select "Norwegian" (for the SIL EuroLatin keyboard)
Tap the spacebar. (The keyboard should be on the default [lowercase] layer after this.)
Tap the shift key once.
Verify that the keyboard changes to, and stays on, the shift layer.

TEST_BASIC_MODIPRESS: Using the standard "Test unminified KeymanWeb" test page from a mobile device...

Select "Norwegian" (for the SIL EuroLatin keyboard)
Tap the spacebar. (The keyboard should be on the default [lowercase] layer after this.)
Tap and hold the shift key.
Verify that the keyboard changes to the shift layer.
Tap the A key, verifying that it produces an A.
Release the shift key.
Verify that the keyboard changes to the default layer as a result of step 6.
Repeat steps 3 through 7 quickly, holding shift just long enough to tap the shift layer's A key, then releasing quickly.

TEST_BASIC_MODIPRESS_HOLD: Using the standard "Test unminified KeymanWeb" test page from a mobile device...

Select "Norwegian" (for the SIL EuroLatin keyboard)
Tap the spacebar. (The keyboard should be on the default [lowercase] layer after this.)
Tap and hold the shift key.
Verify that the keyboard changes to the shift layer.
Wait at least one second.
Release the shift key.
Verify that the keyboard changes to the default layer as a result of step 6.

TEST_NUMERIC_FROM_SHIFT: Using the standard "Test unminified KeymanWeb" test page from a mobile device...

Select "Norwegian" (for the SIL EuroLatin keyboard)
Tap the spacebar. (The keyboard should be on the default [lowercase] layer after this.)
Tap the shift key, making the shift layer active.
Tap and hold the numeric key (123) underneath the shift key.
Verify that the keyboard changes to the numeric layer - numbers in the top row, mathematical symbols elsewhere.
Longpress the % key and select the ‱ subkey.
Verify that ‱ is emitted as text.
Release the numeric key.
Verify that the keyboard changes back to the shift layer.
Tap the numeric key, releasing it immediately.
Repeat steps 6 and 7, longpressing the % key and select the ‱ subkey.
Verify that the keyboard automatically changes back to the default (lowercase) layer.

TEST_DELAYED_SUBKEY: Using the standard "Test unminified KeymanWeb" test page from a mobile device...

Select "Norwegian" (for the SIL EuroLatin keyboard)
Tap the spacebar. (The keyboard should be on the default [lowercase] layer after this.)
Tap the shift key, making the shift layer active.
Tap and hold the numeric key (123) underneath the shift key.
Verify that the keyboard changes to the numeric layer - numbers in the top row, mathematical symbols elsewhere.
Longpress the % key, but do not select a subkey yet.
Release the numeric key.
Verify that the keyboard changes back to the shift layer, with the subkey menu still displayed.
Select the ‱ subkey.
Verify that ‱ is emitted as text and that the layer does not change as a result.

TEST_DOUBLETAP_CAPS: Using the standard "Test unminified KeymanWeb" test page from a mobile device...

Select "Norwegian" - you should then see "Norwegian - EuroLatin (SIL)" in the space bar.
Type All .
Double-tap the shift key. Afterward, the shift key should be highlighted, and its up-arrow should have a thin line underneath, as if underlining it.
Without touching the shift key at any point, type CAPS .
- If this is impossible - i.e., the layer shifted out from underneath you - FAIL the test.
Single-tap the shift key. Afterward, you should be returned to the base layer.
Type work .
Tap the shift key once.
Without touching the shift key at any point, type Well.
- If this is impossible - i.e., the layer did not drop the the base layer when expected - FAIL the test.
- Expected final result, in total: All CAPS work Well

TEST_CUSTOM_MULTITAP_MODIFIER: Using the standard "Test unminified KeymanWeb" test page from a mobile device...

Select "English...", then "Gesture Prototyping".
Tap and hold the ◌́ key. (The key between the spacebar [left] and the Enter key [right].)
A number of letters, including all of the vowels, should change to versions using the ◌́ accent mark.
Tap the à and verify that the corresponding letter is output.
Release the ◌́ key; you should be returned to the default layer.
Note the hints on the ◌́, then triple-tap it, holding on the third tap.
A number of letters, including all of the vowels, should change to versions using the ◌̂ mark
- This corresponds to the second diacritic from the ◌́-key's hint.
Tap the â and verify that the corresponding letter is output.
Release the ◌́ key; you should be returned to the default layer.

TEST_MISCELLANEOUS: If anything you consider an error or bug occurs that seems unrelated to the tests, please note it here.

If you see something you'd normally report as a bug when regression testing, FAIL this "test" and document the bug here.
An actual regression-test run will be requested later on, so don't feel the need to perform a full regression-test set at this time.

The removed block could cause race-condition-like errors due to async input handling

keymanapp-test-bot · 2023-10-27T06:55:18Z

User Test Results

Test specification and instructions

✅ TEST_BASIC_SIMPLE_SHIFT (PASSED): Tested in an Android mobile device (Samsung Galaxy A23 5g - Android Version 13) using the standard "Test unminified KeymanWeb" test page and here is my observation: 1. Set "Norwegian - EuroLatin" keyboard. 2. Tapped the spacebar. The default [lowercase] layer appears on this keyboard. 3. Tapped Shift key. Verified that the keyboard changed to shift layer. (notes)
✅ TEST_BASIC_MODIPRESS (PASSED): 1. Set the "Norwegian - EuroLatin(SIL)" keyboard. 2. Tapped the space bar. verified that the keyboard shows default (lowercase) layer. 3. Tapped and hold the shift key. Verified that the keyboard changed to the shift layer. 4. Tapped the 'A' key. Verified that it produces an A on the text box. 5. Release the Shift key. Verified that the keyboard changed to the default layer. 6. Repeat the steps from 3 through 7 quickly, output the A character on the text box and verified that the keyboard is in the default layer. (notes)
✅ TEST_BASIC_MODIPRESS_HOLD (PASSED): 1. Set the "Norwegian - EuroLatin" keyboard. 2. Tapped the spacebar. The keyboard shows the default layer. 3. Tapped and hold the shift key. Verified that the keyboard changed to the shift layer. 4. After a second, I released the Shift key. Verified that the keyboard changes to the default layer. (notes)
✅ TEST_NUMERIC_FROM_SHIFT (PASSED): 1. Set the "Norwegian - SIL Eurolatin" keyboard. 2. Tapped the spacebar. The keyboard shows the default layer. 3. Tapped the shift key to make the shift layer active. 4. Tapped and hold the numeric key (123). Verified that the keyboard changed to the numeric layer. 5. Long-press the % key then clicked the ‱ subkey. Verified that it outputs ‱ on the text box. 6. Released the Numeric key. Verified that the keyboard changed back to the shift layer. 7. Repeat the steps 6 and 7 and the expected output ‱ appear again and again on the text box. Also, verified after releasing the numeric key, the keyboard automatically changed back to the default (lowercase) layer. (notes)
✅ TEST_DELAYED_SUBKEY (PASSED): 1. Set the "Norwegian - SIL Eurolatin" keyboard. 2. Tapped and hold the numeric key underneath the shift key. 3. Verified that the keyboard changed to the numeric layer. 4. Long-pressed the % key, and did not select the subkey. 5. Released the numeric key. Verified that the keyboard changes back to the shift layer, with the subkey menu still displayed. 6. Tapped the ‱ subkey. Verified that ‱ is emitted as text and that the layer did not changed in the keyboard. (notes)
✅ TEST_DOUBLETAP_CAPS (PASSED): 1. Set "Norwegian - EuroLatin(SIL)" keyboard. 2. Typed "All". The text 'All' appeared on the text box. 3. Double-tapped on the shift key. Verified that the shift key was highlighted and its up-arrow appeared with a thin line underneath, as if underlining it. 4. Typed 'CAPS' without touching the shift key. Verified that the corresponding output appear on the text input screen. 5. Single-tapped the shift key. Verified that the keyboard shows the default layer. 6. Typed 'work'. It appears on the screen. 7. Taped the shift key once, then type 'Well' and it shows the corresponding output on the screen. Able to see all the expected outputs on the screen. Seems to be working fine. (notes)
✅ TEST_CUSTOM_MULTITAP_MODIFIER (PASSED): 1. Set the "English - Gesture Prototyping" keyboard. 2. Tapped and hold the ◌́ key. Verified that a number of letters, including all of the vowels are changed to versions using the ◌́ accent mark. 3. Tapped à key and verified that the corresponding letter is output. 4. Released the ◌́ key and verified that the keyboard was in the default layer. 5. Triple tapped on ◌́ key and hold on to the third tap. Tapped the â key and it shows the corresponding output on the screen. Release the ◌́ key and verify that it returns to the default layer. (notes)
✅ TEST_MISCELLANEOUS (PASSED): I haven't encountered any significant problems so far in this test. Anyhow, it would be better to add this test to our regression test. Thanks.

…b/modipress

mcdurdin · 2023-11-02T05:08:13Z

It'd be a "heuristic" of sorts, though - there's nothing stopping someone from special-styling a text-output key that would swap the layer too. Hopefully folks don't consider that a "feature" and instead wisely design their layouts accordingly.

I think we need to make sure our keyboard design guidance notes this.

mcdurdin

A few more thoughts on this one but LGTM once those are addressed

web/src/engine/main/src/keymanEngine.ts

web/src/engine/osk/src/input/gestures/browser/modipress.ts

web/src/engine/osk/src/input/gestures/browser/multitap.ts

web/src/engine/osk/src/input/gestures/specsForLayout.ts

mcdurdin · 2023-11-02T05:20:58Z

web/src/engine/osk/src/visualKeyboard.ts

+          try {
+            if(shouldLockLayer) {
+              this.lockLayer(true);
+            }
+            keyResult = this.modelKeyClick(gestureStage.item, coord);
+          } finally {
+            this.lockLayer(false);
+          }


Why do we need try here? Are we expecting exceptions to be thrown?

Expecting? No, not during standard use. But that's why they're "exceptions". Note: I don't even try to catch them - I'm just looking to ensure a critical recovery step happens even if they occur.

this.modelKeyClick triggers code that links into rule processing, which isn't exactly a narrow area of code. Should something unexpectedly break, we want to at least "unlock" the layer even if an error occurs... otherwise, the OSK will appear to "lock up" to end users, and that's far from ideal.

Sometimes we've seen errors from individual keystrokes that don't break things for other keystrokes. If KMW isn't completely broken, just failing that one keystroke can allow a form of recovery... in which we want to ensure that any layer-lock (modipress) manipulations we do here also recover if possible.

Okay, we just haven't got anywhere near that level of robustness elsewhere in KeymanWeb, so this is a bit of a new pattern.

A text-search across the repo for } finally { actually turns up 8 pre-existing instances of this exact pattern. It's not the first time I've used it like this.

web/src/engine/osk/src/visualKeyboard.ts

…b/modipress

bharanidharanj · 2023-11-03T13:54:48Z

Test Results

TEST_BASIC_SIMPLE_SHIFT (PASSED): Tested in an Android mobile device (Samsung Galaxy A23 5g - Android Version 13) using the standard "Test unminified KeymanWeb" test page and here is my observation: 1. Set "Norwegian - EuroLatin" keyboard. 2. Tapped the spacebar. The default [lowercase] layer appears on this keyboard. 3. Tapped Shift key. Verified that the keyboard changed to shift layer.
TEST_BASIC_MODIPRESS (PASSED): 1. Set the "Norwegian - EuroLatin(SIL)" keyboard. 2. Tapped the space bar. verified that the keyboard shows default (lowercase) layer. 3. Tapped and hold the shift key. Verified that the keyboard changed to the shift layer. 4. Tapped the 'A' key. Verified that it produces an A on the text box. 5. Release the Shift key. Verified that the keyboard changed to the default layer. 6. Repeat the steps from 3 through 7 quickly, output the A character on the text box and verified that the keyboard is in the default layer.
TEST_BASIC_MODIPRESS_HOLD (PASSED): 1. Set the "Norwegian - EuroLatin" keyboard. 2. Tapped the spacebar. The keyboard shows the default layer. 3. Tapped and hold the shift key. Verified that the keyboard changed to the shift layer. 4. After a second, I released the Shift key. Verified that the keyborad changes to the default layer.
TEST_NUMERIC_FROM_SHIFT (PASSED): 1. Set the "Norwegian - SIL Eurolatin" keyboard. 2. Tapped the spacebar. The keyboard shows the default layer. 3. Tapped the shift key to make the shift layer active. 4. Tapped and hold the numeric key (123). Verified that the keyboard changed to the numeric layer. 5. Long-press the % key then clicked the ‱ subkey. Verified that it outputs ‱ on the text box. 6. Released the Numeric key. Verified that the keyboard changed back to the shift layer. 7. Repeat the steps 6 and 7 and the expected output ‱ appear again and again on the text box. Also, verified after releasing the numeric key, the keyboard automatically changed back to the default (lowercase) layer.
TEST_DELAYED_SUBKEY (PASSED): 1. Set the "Norwegian - SIL Eurolatin" keyboard. 2. Tapped and hold the numeric key underneath the shift key. 3. Verified that the keyboard changed to the numeric layer. 4. Long-pressed the % key, and did not select the subkey. 5. Released the numeric key. Verified that the keyboard changes back to the shift layer, with the subkey menu still displayed. 6. Tapped the ‱ subkey. Verified that ‱ is emitted as text and that the layer did not changed in the keyboard.
TEST_DOUBLETAP_CAPS (FAILED): 1. Set "Norwegian - EuroLatin(SIL)" keyboard. 2. Typed "All". The text 'All' appeared on the text box. 3. Double-tapped on the shift key. Noticed that the shift key was not been highlighted. The Keyboard still appear on the default (lowercase) layer. Seems to be an issue.
TEST_CUSTOM_MULTITAP_MODIFIER (FAILED): 1. Set "English - Gesture Prototyping" keyboard. 2. Tapped and hold the ◌́ key. Verified that a number of letters , including all of the vowels are changed to versions using the ◌́ accent mark. 3. Tapped à key and verified that the corresponding letter is output. 4. Released the ◌́ key and verified that the keyboard was in default layer. 5. Triple tapped on ◌́ key and hold on the third tap. Noticed that it did not show up the second diacritic from the ◌́ key's hint. Noticed that à key appears on the text box. Seems to be an issue.

bharanidharanj · 2023-11-03T13:57:33Z

Test Results

TEST_MISCELLANEOUS (PASSED): I haven't encountered any significant problems so far in this test.

jahorton · 2023-11-08T07:40:09Z

@keymanapp-test-bot retest all

While it's nice that some of the tests passed, I've noticed that fixing one aspect sometimes has led me to break others. It's best to do a full retest to ensure nothing is left broken by accident.

bharanidharanj · 2023-11-08T13:11:21Z

Test Results

TEST_BASIC_SIMPLE_SHIFT (PASSED): Tested in an Android mobile device (Samsung Galaxy A23 5g - Android Version 13) using the standard "Test unminified KeymanWeb" test page and here is my observation: 1. Set "Norwegian - EuroLatin" keyboard. 2. Tapped the spacebar. The default [lowercase] layer appears on this keyboard. 3. Tapped Shift key. Verified that the keyboard changed to shift layer.
TEST_BASIC_MODIPRESS (PASSED): 1. Set the "Norwegian - EuroLatin(SIL)" keyboard. 2. Tapped the space bar. verified that the keyboard shows default (lowercase) layer. 3. Tapped and hold the shift key. Verified that the keyboard changed to the shift layer. 4. Tapped the 'A' key. Verified that it produces an A on the text box. 5. Release the Shift key. Verified that the keyboard changed to the default layer. 6. Repeat the steps from 3 through 7 quickly, output the A character on the text box and verified that the keyboard is in the default layer.
TEST_BASIC_MODIPRESS_HOLD (PASSED): 1. Set the "Norwegian - EuroLatin" keyboard. 2. Tapped the spacebar. The keyboard shows the default layer. 3. Tapped and hold the shift key. Verified that the keyboard changed to the shift layer. 4. After a second, I released the Shift key. Verified that the keyboard changes to the default layer.
TEST_NUMERIC_FROM_SHIFT (PASSED): 1. Set the "Norwegian - SIL Eurolatin" keyboard. 2. Tapped the spacebar. The keyboard shows the default layer. 3. Tapped the shift key to make the shift layer active. 4. Tapped and hold the numeric key (123). Verified that the keyboard changed to the numeric layer. 5. Long-press the % key then clicked the ‱ subkey. Verified that it outputs ‱ on the text box. 6. Released the Numeric key. Verified that the keyboard changed back to the shift layer. 7. Repeat the steps 6 and 7 and the expected output ‱ appear again and again on the text box. Also, verified after releasing the numeric key, the keyboard automatically changed back to the default (lowercase) layer.

..NumShift1

..NumShift2

TEST_DELAYED_SUBKEY (PASSED): 1. Set the "Norwegian - SIL Eurolatin" keyboard. 2. Tapped and hold the numeric key underneath the shift key. 3. Verified that the keyboard changed to the numeric layer. 4. Long-pressed the % key, and did not select the subkey. 5. Released the numeric key. Verified that the keyboard changes back to the shift layer, with the subkey menu still displayed. 6. Tapped the ‱ subkey. Verified that ‱ is emitted as text and that the layer did not changed in the keyboard.
TEST_DOUBLETAP_CAPS (PASSED): 1. Set "Norwegian - EuroLatin(SIL)" keyboard. 2. Typed "All". The text 'All' appeared on the text box. 3. Double-tapped on the shift key. Verified that the shift key was highlighted and its up-arrow appeared with a thin line underneath, as if underlining it. 4. Typed 'CAPS' without touching the shift key. Verified that the corresponding output appear on the text input screen. 5. Single-tapped the shift key. Verified that the keyboard shows the default layer. 6. Typed 'work'. It appears on the screen. 7. Taped the shift key once, then type 'Well' and it shows the corresponding output on the screen. Able to see all the expected outputs on the screen. Seems to be working fine.
TEST_CUSTOM_MULTITAP_MODIFIER (PASSED): 1. Set the "English - Gesture Prototyping" keyboard. 2. Tapped and hold the ◌́ key. Verified that a number of letters, including all of the vowels are changed to versions using the ◌́ accent mark. 3. Tapped à key and verified that the corresponding letter is output. 4. Released the ◌́ key and verified that the keyboard was in the default layer. 5. Triple tapped on ◌́ key and hold on to the third tap. Tapped the â key and it shows the corresponding output on the screen. Release the ◌́ key and verify that it returns to the default layer.
TEST_MISCELLANEOUS (PASSED): I haven't encountered any significant problems so far in this test. Anyhow, it would be better to add this test to our regression test. Thanks.

jahorton added 5 commits October 27, 2023 13:11

feat(web): implementation of modipress, compatibility with multitap

1a3d7a2

fix(web): unneeded source-completion check

d2ba7e2

The removed block could cause race-condition-like errors due to async input handling

fix(web): cleanup for cleanup code

86e217a

fix(web): swift longpress's early modipress cancellation

3b28dd2

fix(web): modipressing of a multitap subkey

441600d

keymanapp-test-bot bot added the user-test-missing User tests have not yet been defined for the PR label Oct 27, 2023

keymanapp-test-bot bot added the epic-gestures label Oct 27, 2023

github-actions bot added web/ common/ common/web/ and removed epic-gestures labels Oct 27, 2023

keymanapp-test-bot bot changed the title ~~feat(web): implementation of modipress, integration with multitap~~ feat(web): implementation of modipress, integration with multitap 🐵 Oct 27, 2023

github-actions bot added the feat label Oct 27, 2023

keymanapp-test-bot bot added this to the A17S24 milestone Oct 27, 2023

keymanapp-test-bot bot added the epic-gestures label Oct 27, 2023

jahorton added 2 commits October 27, 2023 14:33

feat(web): modipress detection heuristic

facafe3

fix(web): niche-case handling - subkey from released modipress

0ae48cc

mcdurdin modified the milestones: A17S24, A17S25 Oct 27, 2023

jahorton added 3 commits October 30, 2023 09:24

chore(web): a bit of polish, re-enables a check

96dae39

chore(web): squashes warning when attempting to correct modipresses

d5e704f

chore(web): Merge branch 'feat/web/generalized-multitap' into feat/we…

dd52337

…b/modipress

keymanapp-test-bot bot added has-user-test 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 Nov 1, 2023

jahorton marked this pull request as ready for review November 1, 2023 06:47

jahorton requested a review from mcdurdin as a code owner November 1, 2023 06:47

fix(web): automated-test patchup

b9d02cb

chore(web): now uses common/web/types enum for button classes

44c1a71

jahorton mentioned this pull request Nov 2, 2023

feat(web): generalized multitap 🐵 #9740

Merged

mcdurdin approved these changes Nov 2, 2023

View reviewed changes

jahorton added 5 commits November 3, 2023 09:32

fix(web): fixes modipress issues discovered in personal tests

c1436c6

chore(web): addresses most review concerns

6955f90

chore(web): semi-verbose check for modipress button-class critierion

0897a28

chore(web): Merge branch 'feat/web/generalized-multitap' into feat/we…

2189f1e

…b/modipress

fix(web): modipress+longpress next-layer handling

3ef5519

keymanapp-test-bot bot added the user-test-failed label Nov 3, 2023

keymanapp-test-bot bot removed the user-test-required User tests have not been completed label Nov 3, 2023

jahorton added 4 commits November 6, 2023 08:38

fix(web): modipress on first tap of multitappable

93c1317

fix(web): path with undefined return value in matcherSelector

d227550

chore(web): gesture-engine integration null-guards

8e87e66

chore(web): taggedContext null guard in lm-worker

eb74bb9

keymanapp-test-bot bot added user-test-required User tests have not been completed and removed user-test-failed labels Nov 8, 2023

keymanapp-test-bot bot removed the user-test-required User tests have not been completed label Nov 8, 2023

mcdurdin modified the milestones: A17S25, A17S26 Nov 13, 2023

Base automatically changed from feat/web/generalized-multitap to feature-gestures November 13, 2023 04:02

chore(web): Merge branch 'feature-gestures' into feat/web/modipress

cc9de9d

jahorton merged commit 721c73d into feature-gestures Nov 13, 2023
3 checks passed

jahorton deleted the feat/web/modipress branch November 13, 2023 04:04

jahorton mentioned this pull request Dec 12, 2023

epic: new gesture engine 🐵 #7324

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(web): implementation of modipress, integration with multitap 🐵 #9876

feat(web): implementation of modipress, integration with multitap 🐵 #9876

jahorton commented Oct 27, 2023 •

edited

Loading

keymanapp-test-bot bot commented Oct 27, 2023 •

edited

Loading

mcdurdin commented Nov 2, 2023

mcdurdin left a comment

mcdurdin Nov 2, 2023

jahorton Nov 3, 2023 •

edited

Loading

mcdurdin Nov 3, 2023

jahorton Nov 3, 2023 •

edited

Loading

bharanidharanj commented Nov 3, 2023

bharanidharanj commented Nov 3, 2023

jahorton commented Nov 8, 2023

bharanidharanj commented Nov 8, 2023

	function keySupportsModipress(key: KeyElement) {
	// Future enhancement idea: allow some extra way for a key to say "hi, I'm modipressable".
	const keySpec = key.key.spec;
	const modifierKeyIds = ['K_SHIFT', 'K_ALT', 'K_CTRL', 'K_NUMERALS', 'K_SYMBOLS', 'K_CURRENCIES'];
	for(const modKeyId of modifierKeyIds) {
	if(keySpec.id == modKeyId) {
	return true;
	}
	}

	// Allows special-formatted keys with a next-layer property to be modipressable.
	return keySpec.sp > 0 /* ButtonClasses.normal / && keySpec.sp < 8 / ButtonClasses.deadkey */ && !!keySpec.nextlayer;
	}

	"K_LOPT":50001,"K_ROPT":50002,
	"K_NUMERALS":50003,"K_SYMBOLS":50004,"K_CURRENCIES":50005,
	"K_UPPER":50006,"K_LOWER":50007,"K_ALPHA":50008,
	"K_SHIFTED":50009,"K_ALTGR":50010,

	export const enum TouchLayoutKeySp {
	normal=0,
	/** A 'frame' key, such as Shift or Enter, which is styled accordingly; uses
	* the 'KeymanwebOsk' font on KeymanWeb */
	special=1,
	/** A 'frame' key, such as Shift or Enter, which is styled accordingly and is
	* highlighted to indicate it is active, such as the shift key on a shift
	* layer; uses the 'KeymanwebOsk' font on KeymanWeb */
	specialActive=2,
	/ KeymanWeb runtime private use:** a variant of `special` with the
	* keyboard font rather than 'KeymanwebOsk' font */
	customSpecial=3,
	/ KeymanWeb runtime private use:** a variant of `specialActive` with the
	* keyboard font rather than 'KeymanwebOsk' font. */
	customSpecialActive=4,
	/** A styling signal to indicate that the key may have 'deadkey' type
	* behaviour. */
	deadkey=8,
	/** A key which is rendered as a blank keycap, blocks any interaction */
	blank=9,
	/** Renders the key only as a gap or spacer, blocks any interaction */
	spacer=10
	};

feat(web): implementation of modipress, integration with multitap 🐵 #9876

feat(web): implementation of modipress, integration with multitap 🐵 #9876

Conversation

jahorton commented Oct 27, 2023 • edited Loading

User Testing

keymanapp-test-bot bot commented Oct 27, 2023 • edited Loading

User Test Results

mcdurdin commented Nov 2, 2023

mcdurdin left a comment

Choose a reason for hiding this comment

mcdurdin Nov 2, 2023

Choose a reason for hiding this comment

jahorton Nov 3, 2023 • edited Loading

Choose a reason for hiding this comment

mcdurdin Nov 3, 2023

Choose a reason for hiding this comment

jahorton Nov 3, 2023 • edited Loading

Choose a reason for hiding this comment

bharanidharanj commented Nov 3, 2023

Test Results

bharanidharanj commented Nov 3, 2023

Test Results

jahorton commented Nov 8, 2023

bharanidharanj commented Nov 8, 2023

Test Results

jahorton commented Oct 27, 2023 •

edited

Loading

keymanapp-test-bot bot commented Oct 27, 2023 •

edited

Loading

jahorton Nov 3, 2023 •

edited

Loading

jahorton Nov 3, 2023 •

edited

Loading