erabo/spiegel-keyman
1
0
Fork 0
mirror of https://github.com/keymanapp/keyman.git synced 2026-09-23 16:17:40 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6

Merge branch 'docs/web/gesture-modeling-and-processing' into docs/web/gesture-input-serialization

Browse source
This commit is contained in:
Joshua Horton 2025-04-01 08:59:25 +07:00
commit 63d6df6e00
2 changed files with 9 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
web/docs/internal/gestures/gesture-modeling.md
View file

@ -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`

12
web/docs/internal/gestures/index.md
View file

@ -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.
3. Release of the modipressed key