kb01/zmk
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(docs): change some words to help comprehension

Browse source 
I ran the text through Grammarly. There are a bunch of changes it
suggests still.
This commit is contained in:
Cody McGinnis 2020-08-18 20:23:40 -04:00
parent 06cf336762
commit 767ea5d6ea
1 changed files with 11 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
docs/docs/feature/keymaps.md
View file

@ -4,9 +4,9 @@ title: Keymaps & Behaviors
sidebar_label: Keymaps sidebar_label: Keymaps
--- ---
ZMK uses an declarative approach to keymaps, instead of using C code for all keymap configuration. ZMK uses a declarative approach to keymaps, instead of using C code for all keymap configuration.
Right now, ZMK uses the devicetree syntax to declare those keymaps; future work is envisioned for Right now, ZMK uses the devicetree syntax to declare those keymaps; future work is envisioned for
supporting dynamic loading of declarative keymaps, e.g. over USB Mass Storage or via a custom BLE supporting dynamic loading of declarative keymaps, e.g., over USB Mass Storage or via a custom BLE
service. service.
:::note :::note
@ -16,20 +16,20 @@ in the future by allowing user configs to add to the CMake application built by
## Big Picture ## Big Picture
All keyboard definitions (complete boards or shields) include the _default_ keymap for that keyboard, All keyboard definitions (complete boards or shields) include the _default_ keymap for that keyboard
so ZMK can produce a "stock" firmware for that keyboard without any further modifications. For users so that ZMK can produce a "stock" firmware for that keyboard without any further modifications. For
looking to customize their keyboard's behavior, they can copy the stock `.keymap` file into their users looking to customize their keyboard's behavior, they can copy the stock `.keymap` file into
user config directory, and customize the keymap to their liking. their user config directory, and customize the keymap to their liking.
## Behaviors ## Behaviors
ZMK implements the concept of "behaviors", which can be bound to a certain key position, sensor (encoder), ZMK implements the concept of "behaviors", which can be bound to a specific key position, sensor (encoder),
or layer, to perform certain actions when events occur for that binding (e.g. when a certain key position or layer, to perform particular actions when events occur for that binding (e.g. when a specific key position
is pressed or released, or an encoder triggers a rotation event). is pressed or released, or an encoder triggers a rotation event).
For example, the simplest behavior in ZMK is the "key press" behavior, which responds to key position For example, the simplest behavior in ZMK is the "key press" behavior, which responds to a key position
(a certain spot on the keyboard), and when that position is pressed, send a keycode to the host, and (a certain spot on the keyboard), and when that position is pressed, send a keycode to the host, and
when the key position is released, updates the host to notify of the keycode being released. when the key position is released, updates the host notifying of the keycode being released.
For the full set of possible behaviors, start at the [Key Press](/docs/behavior/key-press) behavior. For the full set of possible behaviors, start at the [Key Press](/docs/behavior/key-press) behavior.
@ -146,7 +146,7 @@ that defines just one layer for this keymap:
Each layer should have: Each layer should have:
1. A `bindings` property this will be a list of behaviour bindings, one for each key position for the keyboard. 1. A `bindings` property that will be a list of behaviour bindings, one for each key position for the keyboard.
1. (Optional) A `sensor-bindings` property that will be a list of behavior bindings for each sensor on the keyboard. (Currently, only encoders are supported as sensor hardware, but in the future devices like trackpoints would be supported the same way) 1. (Optional) A `sensor-bindings` property that will be a list of behavior bindings for each sensor on the keyboard. (Currently, only encoders are supported as sensor hardware, but in the future devices like trackpoints would be supported the same way)
For the full set of possible behaviors, start at the [Key Press](/docs/behavior/key-press) behavior. For the full set of possible behaviors, start at the [Key Press](/docs/behavior/key-press) behavior.