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

refactor(docs): Refer to overview page for behaviors

Browse source
This commit is contained in:
Cem Aksoylar 2024-03-24 17:58:20 -07:00
parent f2d8b9b0a3
commit c684cee76f
3 changed files with 4 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/docs/development/new-behavior.mdx
View file

@ -8,7 +8,7 @@ import TabItem from "@theme/TabItem";
## Overview ## Overview
This document outlines how to develop a behavior for ZMK and prepare the changes for a pull request. This document outlines how to develop a [behavior](../behaviors/index.mdx) for ZMK and prepare the changes for a pull request.
Behaviors are assigned to key positions and determine what happens when they are pressed and released. They are implemented in Zephyr as "devices": they consist of a devicetree binding file, which specifies the properties of the behavior, and a driver written in C code. This allows for the ability to create unique instances of these behaviors in [keymaps](../features/keymaps.mdx) or devicetree-source-include files (`.dtsi`). While instances of behaviors stored in keymaps are created by end-users for their personal needs, the instances that live in the .dtsi files are stored and documented in ZMK directly, which removes the need for end-users to set up common use-cases of these behaviors in their personal keymaps. Behaviors are assigned to key positions and determine what happens when they are pressed and released. They are implemented in Zephyr as "devices": they consist of a devicetree binding file, which specifies the properties of the behavior, and a driver written in C code. This allows for the ability to create unique instances of these behaviors in [keymaps](../features/keymaps.mdx) or devicetree-source-include files (`.dtsi`). While instances of behaviors stored in keymaps are created by end-users for their personal needs, the instances that live in the .dtsi files are stored and documented in ZMK directly, which removes the need for end-users to set up common use-cases of these behaviors in their personal keymaps.

2
docs/docs/development/new-shield.mdx
View file

@ -386,7 +386,7 @@ The two `#include` lines at the top of the keymap are required in order to bring
### Keymap Behaviors ### Keymap Behaviors
For the full documentation on the available behaviors for use in keymaps, start with reviewing [`kp`](../behaviors/key-press.md) and then use the sidebar to review the others available within ZMK. For documentation on the available behaviors for use in keymaps, see the [overview page for behaviors](../behaviors/index.mdx).
## Metadata ## Metadata

6
docs/docs/features/keymaps.mdx
View file

@ -33,7 +33,7 @@ For example, the simplest behavior in ZMK is the "key press" behavior, which res
(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 to notify of the keycode being released.
For the full set of possible behaviors, start at the [Key Press](../behaviors/key-press.md) behavior. For the full set of possible behaviors, see the [overview page for behaviors](../behaviors/index.mdx).
## Layers ## Layers
@ -128,11 +128,9 @@ 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 behavior bindings, one for each key position for the keyboard. 1. A `bindings` property this will be a list of [behavior bindings](../behaviors/index.mdx), 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](../behaviors/key-press.md) behavior.
### Complete Example ### Complete Example
Putting this all together, a complete [`kyria.keymap`](https://github.com/zmkfirmware/zmk/blob/main/app/boards/shields/kyria/kyria.keymap) looks like: Putting this all together, a complete [`kyria.keymap`](https://github.com/zmkfirmware/zmk/blob/main/app/boards/shields/kyria/kyria.keymap) looks like: