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 70305a3ac6..765c67e249 100644 --- a/web/docs/internal/gestures/index.md +++ b/web/docs/internal/gestures/index.md @@ -5,13 +5,13 @@ 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. - [Input serialization](./gesture-input-serialization.md) refers to some of the trickier aspects of handling input to ensure every input event is processed in the correct, user-intended order. - 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. ---- @@ -31,12 +31,14 @@ 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 ### 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 +3. Release of the modipressed key \ No newline at end of file