From 9034e045d6eb5171d571a31816bb72cc59efe06f Mon Sep 17 00:00:00 2001 From: Joshua Horton Date: Tue, 1 Apr 2025 08:41:27 +0700 Subject: [PATCH 1/2] docs(web): Apply suggestions from code review Co-authored-by: Eberhard Beilharz --- web/docs/internal/gestures/gesture-modeling.md | 4 ++-- web/docs/internal/gestures/index.md | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/web/docs/internal/gestures/gesture-modeling.md b/web/docs/internal/gestures/gesture-modeling.md index 00fd2a4a30..4ce2545f5f 100644 --- a/web/docs/internal/gestures/gesture-modeling.md +++ b/web/docs/internal/gestures/gesture-modeling.md @@ -6,8 +6,8 @@ The four layers comprising gesture modeling with `GestureRecognizer` are as foll 1. [`GestureModelDefs`](#gesturemodeldefs) corresponds to the top-most object used to specify gesture definitions. It represents a full set of custom gesture-component definitions as well at least one set of gesture-component ids that corresponds to legal initial gesture-components for a newly-beginning gesture sequence. 2. Each [`GestureModel`](#gesturemodel) object directly models a gesture-component. To do so, it owns at least one `ContactModel` and defines the gesture-component's properties and relationships to other gesture-components. Also defines a start-up timer for cases that lack active touchpoints during startup, such as the "wait" for the start of a second tap during multitap gestures. -2. Each [`ContactModel`](#contactmodel) owns a single `PathModel` and is additionally responsible for validating initial state, changes in associated item, and the portion of previously-existing path to consider if continuing an active gesture sequence. -3. [`PathModel`](#pathmodel) specifies which paths do and do not satisfy the requirements for the touchpoint handled by the `ContactModel` owning it. +3. Each [`ContactModel`](#contactmodel) owns a single `PathModel` and is additionally responsible for validating initial state, changes in associated item, and the portion of previously-existing path to consider if continuing an active gesture sequence. +4. [`PathModel`](#pathmodel) specifies which paths do and do not satisfy the requirements for the touchpoint handled by the `ContactModel` owning it. ## `GestureModelDefs` diff --git a/web/docs/internal/gestures/index.md b/web/docs/internal/gestures/index.md index 7181b5593f..1f34bc7ade 100644 --- a/web/docs/internal/gestures/index.md +++ b/web/docs/internal/gestures/index.md @@ -8,9 +8,9 @@ There are a few different aspects to GestureRecognizer, each with its own intern - [Gesture processing](./gesture-processing.md) refers to the process of interpreting the user's input as gestures. - The [Glossary](./glossary.md) provides definitions for some of the terms seen among the internal documentation pages. -There is also documentation regarding some of the trickier aspects of [configuring the region that accepts gestures](./recognizer-configuration.md) +There is also documentation regarding some of the trickier aspects of [configuring the region that accepts gestures](./recognizer-configuration.md). -Keyman configures two separate instances of this gesture engine - one for main keyboard body and another for the predictive-text banner. In both cases, gestures (from the user perspective) are broken own into components, each corresponding to different movement patterns that comprise a each gesture type. Once components are recognized, they are added into a sequence that represents the causal relationship among the different components of the gesture and ensures that it may continue if appropriate for that type of gesture. +Keyman configures two separate instances of this gesture engine - one for main keyboard body and another for the predictive-text banner. In both cases, gestures (from the user perspective) are broken down into components, each corresponding to different movement patterns that each comprise a gesture type. Once components are recognized, they are added into a sequence that represents the causal relationship among the different components of the gesture and ensures that it may continue if appropriate for that type of gesture. ---- @@ -30,7 +30,7 @@ Components: 4. Flick end - the user has input enough motion to confirm the flick _and_ released the touchpoint. ### Multitap -1. First tap - the user has tapped a key. +1. First tap - the user has tapped a key 2. Awaiting the next tap 3. Awaiting release of the current tap 4. Exit case: a key was held too long - no further taps on the key should be considered part of the gesture @@ -38,4 +38,4 @@ Components: ### Modipress 1. The user holds down on a modipress-friendly key 2. Engine alt-state: a different set of initial gesture components is activated and used for newly-starting concurrent gestures -3. Release of the modipressed key. \ No newline at end of file +3. Release of the modipressed key \ No newline at end of file From 3ed52349d3bd68fe738550a2483fb17ab07fe881 Mon Sep 17 00:00:00 2001 From: Joshua Horton Date: Tue, 1 Apr 2025 08:50:19 +0700 Subject: [PATCH 2/2] docs(web): addresses more review concerns --- web/docs/internal/gestures/index.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/web/docs/internal/gestures/index.md b/web/docs/internal/gestures/index.md index 1f34bc7ade..d69593458a 100644 --- a/web/docs/internal/gestures/index.md +++ b/web/docs/internal/gestures/index.md @@ -5,7 +5,7 @@ GestureRecognizer is an engine designed to interpret mouse event paths and touch There are a few different aspects to GestureRecognizer, each with its own internal doc. - [Gesture modeling](./gesture-modeling.md) refers to the specification of gestures to be interpreted from the user's input. -- [Gesture processing](./gesture-processing.md) refers to the process of interpreting the user's input as gestures. +- [Gesture processing](./gesture-processing.md) refers to the process of interpreting the user's input as from among the specified gesture models. - The [Glossary](./glossary.md) provides definitions for some of the terms seen among the internal documentation pages. There is also documentation regarding some of the trickier aspects of [configuring the region that accepts gestures](./recognizer-configuration.md). @@ -36,6 +36,8 @@ Components: 4. Exit case: a key was held too long - no further taps on the key should be considered part of the gesture ### Modipress +- A "modipress", or "**modi**fier-key long**press**", refers to the act of holding down a modifier key, typing on the resulting layer, and then reverting the layer once the modifier key is released. In essence, using the modifier key like a longpress, with the pushed "layer" acting as its "subkey menu". + 1. The user holds down on a modipress-friendly key 2. Engine alt-state: a different set of initial gesture components is activated and used for newly-starting concurrent gestures 3. Release of the modipressed key \ No newline at end of file