-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
> One can try to get away with very few keys ... The first thing I added was two columns on the right side that kinda just bring back the punctuation
I'd say if you look at a layout like miryoku https://github.com/manna-harbour/miryoku .. in miryoku, the [] keys are one row up from home row, accessed on a layer. Whereas, putting [] on outer columns, your hand has to move and reach over two rows.
That is, I'd emphasise layering brings more keys to within easy access of the fingers (at the cost of added complexity to use the keyboard, - which not everyone has the taste for).
Standard keyboards use a mix of 0.25u and 0.5u stagger, depending on the row.
The Zlant is a uniform-stagger board I got once as a fun project, but you'll see the stagger difference right away: https://github.com/qmk/qmk_firmware/blob/master/keyboards/zl...
This idea falls apart in games that use complex key combinations, or a lot of different keys (like in case of StarCraft 2). I have an ErgoDox and I wish it had an extra dedicated row for F-keys; my current use of the bottom row for camera hotkeys is a very poor compromise.
http://www.keyboard-layout-editor.com/#/gists/8b8dcd36c0abcc... https://gist.github.com/rollcat/8b8dcd36c0abccf430b4160ad899...
I love having a split keyboard. It feels far more ergonomic than a single piece keyboard. Just relax your arms and put each half where your hands are. No having to bring your hands together and angle your wrists to get your hands in position.
The other piece of the puzzle for me is curvature. On a flat keyboard there is more stretching or physically moving but adding in a bit of curvature helps cut down on that.
For a few years now I have been using a Dactyl-ManuForm [1] and it has been great. At least for writing / programming. I go back to a regular keyboard for gaming purposes.
[1] https://github.com/tshort/dactyl-keyboard
Not sure if the author of the post is around, but I guess this is a question for anyone who has designed keyboards: have you ever tried using shift registers for reading all the keyswitch inputs, and is it worth it? Does it mean you don't have to use a diode per switch?
I've designed my own as well but just went with the traditional key matrix with a diode per switch. Works well enough for the current size.
https://github.com/bschwind/key-ripper
Last time i researched adding shift registers was over a year ago and I didn’t find many examples (I vaguely recall one possibly with qmk), and very little public discussion besides a reddit question. Popular guides like ai03’s at the time recommended upgrading to a microcontroller with more gpio before introducing shift registers.
Searching again, looks like zmk added support for the common 595 shift register: https://github.com/zmkfirmware/zmk/pull/1325