Crates.io | oak-type |
lib.rs | oak-type |
version | 0.1.0-alpha |
source | src |
created_at | 2023-02-17 06:20:01.299502 |
updated_at | 2023-02-18 06:46:24.665273 |
description | Open Analog Keyboard |
homepage | https://www.oaktype.org |
repository | |
max_upload_size | |
id | 787291 |
size | 10,554 |
Oak-Type's purpose is to be an analog-first firmware for keyboards and other computer input devices, with an easily adjustable module system for defining new types of inputs and outputs.
While oak-type should be able to handle digital inputs, the first first-class input type is analog. Analog keyboard inputs enable features such as varying the input based on how deep a key is pressed; differential inputs, such as sending a signal while the key is going down, and stopping as soon as the key starts going up; and joystick-like inputs for steering right from wasd.
With config files that can be deployed after the firmware is flashed, QOL options start to open up.
Layers are fantastic, and pass through keys that aren't configured on one layer functioning the way they do on the next lower layer saves a lot of time writing config files, but leaves a little to be desired.
In a tree structure, a board's root layer could be a typical qwerty, dvorak, or colemak layout. The first branch could be games, disabling the meta key, with minor differences for what game or genre you're playing. Another could be for coding modifying an underscore key to a sticky shift when switching between a snake-case and camel-case language.
Another option could be for OS level differences. I hate reaching for the meta key when working in one OS, when my brain tells me I need the cmd key. If they are the same button, the brain doesn't have to care after the layer is changed
root
├─ games
│ ├─ shooter
│ ├─ rhythm
│ ├─ rts
├─ coding
│ ├─ Rust
│ ├─ Python
│ ├─ Java
├─ vim