-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(web): generalized multitap 🐵 #9740
Conversation
User Test ResultsTest specification and instructions
Test Artifacts
|
static dfltShiftMultitap: LayoutSubKey = { | ||
// Needs to be something special and unique. Typing restricts us from | ||
// using a reserved key-id prefix, though. | ||
id: "T_MT_SHIFT_TO_CAPS", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would love to give this a truly unique identifier... perhaps something prefixed with S_
(as in, "special") or I_
(as in, "internal")... but the strict typing currently in place in common/web/types
prohibits that.
keyman/common/web/types/src/keyman-touch-layout/keyman-touch-layout-file.ts
Lines 42 to 44 in 8479ebd
type Key_Type = 'T'|'K'|'U'|'t'|'k'|'u'; | |
type Key_Id = string; | |
export type TouchLayoutKeyId = `${Key_Type}_${Key_Id}`; // pattern = /^[TKUtku]_[a-zA-Z0-9_]+$/ |
While Web doesn't have to be completely bound to the typing there... the typing, as is, is not particularly adaptable. I'd have to redefine nearly all the touch-layout types within Web to permit use of the extra key ID prefix were that to be the way forward. Same issue arises if we were to signal that id
may be undefined
or ''
.
Alternatively, I could just... not preprocess the key and dynamically rebuild the subkey array every time at runtime... but I'm not convinced that's the best idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The typing is there for a reason: it helps us avoid introducing hidden private use types of identifiers in any of the various places these identifiers are used. Leaky abstractions and all that. Yeah, exactly like this case! So this time, at least, the typing is doing its job.
All that said, I'm really happy to look at sensible ways to extend the typespace for private use. I am hesitant to add a new Key_Type
because we'd need to audit all the uses to make sure we don't accidentally break e.g. validation in the compiler. But given the Key_Id
is limited to an alnum_
pattern, couldn't we do something as simple as T_*_MT_SHIFT_TO_CAPS
?
Then all I'd ask is that we add a comment to the keyman-touch-layout-file.ts explaining this private use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I should also add that this type is an input type for a data structure that's meant to be very rigid. We never want to see undefined
or S_foo
in .keyman_touch_layout files. So it wouldn't be appropriate to be extending the types for the input data structures, rather it would be appropriate for KeymanWeb to have its own 'subclassing' of the structures and types to avoid mixing implementation and data details.
bba5473
to
b669201
Compare
3d6e2be
to
f8ae8c9
Compare
…to change/common/models/pred-text-context-tracking
…king' into feat/web/generalized-multitap
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I like the way that you've implemented this. Particularly the clean and declarative approach to handling shift->caps multitap.
Now for something exciting - implementation of one of our long-anticipated new gesture types... the multitap. This is one of the big goals of #5029.
That said... wow, the complications that arise when a key can result in both a modipress and multitap! Resolving that took significant effort and care... and admittedly, modipress still isn't actually implemented. The new
'modipress-multitap-*
gesture-model specs are necessary in order to allow a modipressable key to multitap; modipresses should layer-swap on keydown and fully resolve on keydown+time - which requires two models, while multitaps are triggered by the keyup after the keydown that instantly meets the conditions necessary for modipress's layer-swap event.Short version... I implemented "enough" of modipress to ensure that multitaps can work on modipress keys, but went no further. Modipress state management hasn't been implemented yet.
Not yet done as of this PR:
Currently done:
And, with this... we should actually be able to start proper user testing & regression testing; we should be at full feature-parity with KMW 16.0 and its OSK, with the addition of other keys being able to request multitaps. So...
User Testing
TEST_DOUBLETAP_CAPS: Using the standard "Test unminified KeymanWeb" test page from a mobile device...
All
.CAPS
.work
.Well
.All CAPS work Well
TEST_10_KEY_ROTA: Using the standard "Test unminified KeymanWeb" test page from a mobile device...
8
key once, then wait for a second.8
key twice in quick succession, then wait for a second.8a
.8
key continuously for at least 2 seconds.8a8
,8aa
,8ab
,8ac
,8aA
,8aB
,8aC
, then back to8a8
(and continue from there)9
key once. AD
should be emitted as the result.9
for at least five seconds, paying attention to the key hints.TEST_10_KEY_DIACRITICS: Using the standard "Test unminified KeymanWeb" test page from a mobile device...
8
key.à
à
.9
key.àê
ê
4
key once.8
key.àềa
à
's accent-mark on top the originalê
, as in the cropped screenshot above.a
.TEST_CUSTOM_MULTITAP_MODIFIER: Using the standard "Test unminified KeymanWeb" test page from a mobile device...
◌́
key. (The key between the spacebar [left] and the Enter key [right].)◌́
accent mark.à
and verify that the corresponding letter is output.abc
key (which has replaced the◌́
on the active layer), returning to the default layer, then wait for at least a second.◌́
, then triple-tap it.◌̂
mark◌́
-key's hint.â
and verify that the corresponding letter is output.TEST_MISCELLANEOUS: If anything you consider an error or bug occurs that seems unrelated to the tests, please note it here.