Here is my elaborate strategy for my “maxtend” key on the CapsLock position (I believe the original UHK labels it as the “mouse” key). I write using Colemak, and that key in Colemak is used as backspace. So what I want to achieve is:
short tap = backspace
long hold = mod layer (“maxtend”)
I also want some way to auto-repeat backspace. I use shift + hold for that.
The macro will show on the LED display which function it has triggered.
ifShift goTo shiftMaxtend
resolveSecondary 150 0 primaryaction secondaryaction
secondaryaction:
setLedTxt 0 MAX
holdLayer mod
ifReleased setLedTxt 1 MAX
break
primaryaction:
tapKey backspace
setLedTxt 500 <--
break
shiftMaxtend:
setLedTxt 0 <--
suppressMods holdKey backspace
ifReleased setLedTxt 1 MAX
LED display:
when the “maxtend” layer is triggered, the display will show “MAX”. When you release it, it will switch back to the previous keymap name by setLedTxt 1 MAX, which sets it to “MAX” again, but expires after 1ms, then switches back to whatever the current keymap name is.
when briefly tapping and therefore sending a backspace, the display will show “<—” for 500 ms.
when pressing the key together with shift, it will hold backspace (allowing you to auto-repeat backspace), and the display will show “<—” for as long as you are holding the key. Again the display is switched back to the current keymap name by (ab)using a setLedTxt 1 MAX.
I see. Even then it might be worth to consider to change the default to a typing friendly config and let the gamers then optimize for their needs.
Mmh, that is indeed a problem. I do not have the experience, but I guess that it should be possible to come up with a default delay time which works for the majority of people – at least as a starting point before one “needs” to customize. While I have the impression (which might be wrong) that the current default SecondaryRole is is not a good strategy for keys which output a literal. For modifier keys that likely is different and the current strategy can work? From a (new) user point of view it would be optimal, when the default strategy “just works”. So for alphanumeric keys possibly a different strategy could be applied silently or visible than for other keys. But minimizing the need for many users to have to find or write a macro. It is super cool that macro’s are possible and fine-tuning is relatively easy, but still the default behavior “out of the box” should work for most use cases and most people directly.
I think a strong point of UHK is that some good defaults are chosen (Alt-Tab is already assigned, navigation layer…) That makes it starter friendly. And then one can always customize to change to own wishes and needs. I was pretty frustrated when I bought another ergonomic keyboard, because I felt that exactly those thoughts have been left to each single user. While the keyboard software of that product allows to come up with great solutions, everybody needs to sit down and start from scratch, which in my opinion is not optimal and a reason why I would not recommend the other product, while I happily will recommend UHK.
Looking forward to it.
I was talking about the default configuration (see my answer to Karel above) – regardless were this is stored. Likely in the EEPROM of the UHK, but that does (in an ideal case) not matter to the user.
Very nice example. Thanks for sharing. I will surely “steal” some ideas from it.
