Documentation of Input Action to Processing by Kanata and the System to Output Action

[thomastthai]

Perhaps I missed a documentation or reference that shows the general flow of input actions, and how they are processed by Kanata and the OS with consideration for *-timeouts, repeat, etc. to output actions, i.e. a manual walk-through of the flow.

Such a reference may help new Kanata users understand how input actions translate to output actions.

[jtroo]

I don't precisely understand what you're looking for. Something like the design doc?

https://github.com/jtroo/kanata/tree/main/docs

[thomastthai]

I've read all the docs in that folder and none of them describe what I think would benefit the community in the way I was trying to describe. There is a chance my brain got mushy from all that reading and forgot!

For the Kanata Simulator, the user enters some input action. The Simulator processes the input action and spits the output action taking into account the parameters in the configuration.kbd file. What would be helpful is a document that walks users through and describes that entire process using some common configurations.

Let's take the recent Simulator you helped me with as an example or something simpler, and describe in layman's term, step-by-step, how each input action was processed to arrive at the output actions. Something like:

Let's start with line one, d:a t:70 u:a t:70 d:a t:70.

1. The a key was pressed down for 70ms and released. That generated the output action:

t:              70ms
out:   ↓(press) A
t:              6ms
out: ↑(release) A
t:              64ms

2. The reason 70ms was shown first is because ...
3. Key a is show pressed down
4. It took 6ms before key a is shown as released because ...
5. Then 64ms passed. It's 64ms instead of 70ms from the input action because ...
6. These are taps of the a key instead of a hold of the a key because ... 140ms (70x2) between taps and not 210ms (70x3)
7. ...

In summary, tell the story of what happened to the input actions, how they get processed by Kanata and the OS, and why the output actions are the way they are. The Simulator is an excellent tool to pair with those stories. Two or three stories of different setups will help guide people to "get the picture" of how Kanata works from a non-programmer perspective.