number pad

friday, 15 january 2021

BEAKL Wi saw the first changes to the Number Layer after a long history of BEAKL iterations, with the placement of the numbers in their order of frequency – by finger row and column priority. While a radical departure from the more traditional ascending keypad order, the resultant mapping turned out to be more easily adapted to than anticipated.

The left hand hexadecimal pad which previously “mirrored” the right hand outer roll for the letters was subsequently also changed – inverted and rearranged alphabetically with the F falling on the home row index finger position. All things being equal, hex strings (colour codes, at least) are seemingly random with FFFFFF for white being the most recognizable (and used?) value (and 000000 for black).

Hex strings themselves are case indifferent. So the keymap sources allowed for configuring at compile time the desired case for the hex keypad. Enter..

hex case

toggling so that editing hexadecimal values may be matched to the original author’s style. It doesn’t ultimately make any difference as stated but, with the adaptability of the pinkie stagger, it was only a matter of time to accommodate this.

And so, a CapsLock like key for the hexadecimal keypad has been added to the Number Layer (supplanting the config.h upper or lower case only limitation)..

Corne BEAKL Wi-x Numbers and FnKeys

Tap key actions for..

keycode single tap double tap
Dot   Colon
Comma   Semicolon
Caps Hex lower -> UPPER case  
Brkt Square -> Round -> Curly brackets  

The key is positioned on the free hand side rather than the traditional left hand CapsLock position – since the left thumb raises the layer.

Lastly, there is also a..


key. This allows cycling the left hand brackets from Square to Round to Curly brackets, saving the need to switch to the Regex Layer when inputting numeric arrays, tuples, tables, etc.

The setting, like the hex CapsLock is persistent (until the keyboard is disconnected) and is merely a convenience for data entry – not really a personal need but the fixed square brackets felt like an omission.

The toggled Number LoyerNum key on the rightmost column – loses the toggle key itself for returning to the base layer. The Escape key must be used in this instance to release the layer.

under the hood

typing strings on the hexadecimal keypad isn’t a heavily used pastime (for me, at least) but having time to play around with the Number Layer did reveal an undesirable characteristic.

With the left thumb holding the layer, typing hexadecimal strings can inadvertently register the assigned modifiers instead. This is not due so much to lazy touch typing form as to the hand positioning restriction imposed by the fixed thumb down.

Enter rolling modifier key handling. By extending the mod_roll() function to accommodate a second modifier – the Alt key combinations defined for my particular desktop workflow – and the keycode shift state (for the selectable hex case above)..

#define HEX(m, m2, k, c) mod_roll(record, m, m2, hexcase, k, c) bool process_record_user(uint16_t keycode, keyrecord_t *record) { switch (keycode) { ... case HEX_A: HEX(0, 0, KC_A, 1); break; case ACT_B: HEX(KC_LALT, KC_LCTL, KC_B, 2); break; case HEX_C: HEX(0, 0, KC_C, 3); break; case CT_D: HEX(KC_LCTL, 0, KC_D, 1); break; case AT_E: HEX(KC_LALT, 0, KC_E, 2); break; case ST_F: HEX(KC_LSFT, 0, KC_F, 3); break; ...

Presto! unintended modifiers can be avoided. The brackets in the bottom row are similarly handled.

»»  extreme beakl wi

comment ?