As a user, I would like to have more control over the definition of the Navigation and Function layers. They are essentially an aggregation of two “half-layers”, and I think it would be handy to be able to choose which half layers we want individually from the rest of the config.
Context
We’ve seen people on Discord use mostly what we’ve provided, but swapped out half of a layer here and there :
- Ash uses both the Nav-Num layer (Emacs-style navigation) and the Num-Row (Vim-style numbers)
- Tam uses the Vim navigation option, but swapped Navigation’s right hand for
IJKL style arrows (basically a mirror of the left hand of Nav-Num).
- I myself don’t use the function-pad, but would appreciate having a Num-Pad on the left hand (probably with a layer lock ?) for use in a mouse + keeb context.
What this implies
Basically, we’d need to extract those layers into two half-layers into a half_layers.dtsi file (kind of what we did for the hold taps) :
- Nav-Num =
HL_ARROWS_ESDF + HL_NUMPAD
- Vim-Nav =
HL_CONTROL + HL_ARROWS_HJKL
- Fun-Media =
HL_FUNPAD + HL_MEDIA
Next we’d rework the settings.h file to be able to specify which half layers we want, but this could probably be done by just defining symbols for Nav / Fun + Left / Right, with their default value corresponding to what we have right now in the emacs mode.
Known issues
-
Handedness:
I’m pretty bad at naming things in general (I’m sorry), but I feel like we have to take the handedness into account when defining those layers. The “media” half layer is currently defined for the right hand, and we’ll probably need to reverse it to use it on the left hand. Problem is, that some layers cannot be inverted by having all of their keys swap in the same way (mirroring arrows would result in having the left key on the right, and vice-versa).
-
Num-Row:
Do we create a new flag to enable the Num-Row, or do we just always define it and let people ignore it ? I’m guessing the first option, to be able to still have quick access to the Function layer when using the HRM hold-tap flavor. This means that to fit Ash’s use-case, we probably need to add a transition to that layer in the Nav layer, that needs to be handled right (i.e. defined only when specified, and with the correct timings).
-
Thumb Keys:
Should the half layers define what the thumb keys do ? This could be useful for things like a mouse emulation half layer (to use the thumb keys as the different clicks), but could cause issues in other places, mainly things like layer transitions or the bootloader key, which really depend on which layer they’re on, and not which half-layer.
As a user, I would like to have more control over the definition of the Navigation and Function layers. They are essentially an aggregation of two “half-layers”, and I think it would be handy to be able to choose which half layers we want individually from the rest of the config.
Context
We’ve seen people on Discord use mostly what we’ve provided, but swapped out half of a layer here and there :
IJKLstyle arrows (basically a mirror of the left hand of Nav-Num).What this implies
Basically, we’d need to extract those layers into two half-layers into a
half_layers.dtsifile (kind of what we did for the hold taps) :HL_ARROWS_ESDF+HL_NUMPADHL_CONTROL+HL_ARROWS_HJKLHL_FUNPAD+HL_MEDIANext we’d rework the
settings.hfile to be able to specify which half layers we want, but this could probably be done by just defining symbols for Nav / Fun + Left / Right, with their default value corresponding to what we have right now in the emacs mode.Known issues
Handedness:
I’m pretty bad at naming things in general (I’m sorry), but I feel like we have to take the handedness into account when defining those layers. The “media” half layer is currently defined for the right hand, and we’ll probably need to reverse it to use it on the left hand. Problem is, that some layers cannot be inverted by having all of their keys swap in the same way (mirroring arrows would result in having the left key on the right, and vice-versa).
Num-Row:
Do we create a new flag to enable the Num-Row, or do we just always define it and let people ignore it ? I’m guessing the first option, to be able to still have quick access to the Function layer when using the HRM hold-tap flavor. This means that to fit Ash’s use-case, we probably need to add a transition to that layer in the Nav layer, that needs to be handled right (i.e. defined only when specified, and with the correct timings).
Thumb Keys:
Should the half layers define what the thumb keys do ? This could be useful for things like a mouse emulation half layer (to use the thumb keys as the different clicks), but could cause issues in other places, mainly things like layer transitions or the bootloader key, which really depend on which layer they’re on, and not which half-layer.