You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could do something like automatically duplicate the entire /git/ layer in a /git_OSL/ and add the var() event, and have OSL(git) activate /git_OSL/ instead of /git/, but as far as the configuration is concerned it just looks like editing the /git/ layer.
Tap-Toggle
TT(layer) - Layer Tap-Toggle. If you hold the key down, layer is activated, and then is de-activated when you let go (like MO). If you repeatedly tap it, the layer will be toggled on or off (like TG). It needs 5 taps by default, but you can change this by defining TAPPING_TOGGLE -- for example, #define TAPPING_TOGGLE 2 to toggle on just two taps.
Needing multiple taps to activate a layer would be a nightmare (you'd need to create a layer that measures each tap) and then, since I have yet to implement to_delayed_action, there's no time-out to reset the count.
Translation:
From base layer, if j is held, /target/ is turned on, and then off on release. If it's tapped, j turns on the /helper/ layer. From the helper layer, a second j tap turns on the /target/ layer and turns off the /helper/ layer. A third j tap turns /target/ off.
But this locks you out of repeated keypresses in the base layer, so I would set these up in the /nav/ layer instead. I think the mental overhead is still acceptable at this point, so long as you're ok with two-tap activation.
The karaml-friendly way would be to allow this:
/base/:
<a-j>: [/target/, /target/]
The reason this doesn't work now is because setting a /layer/ in the second position automatically registers a {set_variable: { name: layer_name, value: 0} } map in the to_after_key_up nested dictionary. So whether you tap or hold, the layer gets switched off when the key is released. Bad oversight on my part. More bubblegum code can probably fix this.
TO (toggle off?) layer
TO(Layer) - activates layer and de-activates all other layers (except your default layer).
This seems doable - store a list of all layers before creating the translated-mappings and with a special-event/pseudo function, add all the necessary set_variable events, e.g. to(layer_name).
Default Layer
DF(layer) - switches the default layer. The default layer is the always-active base layer that other layers stack on top of. ...
This one likely isn't possible without a rewrite (which I'd like to do someday)
Layer-Mod
LM(layer, mod) - Momentarily activates layer (like MO), but with modifier(s) mod active. Only supports layers 0-15. The modifiers this keycode accept are prefixed with MOD_, not KC_. These modifiers can be combined using bitwise OR, e.g. LM(_RAISE, MOD_LCTL | MOD_LALT).
I think the same thing can be achieved with a combination of sticky() and var() with relatively little mess? So maybe a new pseudo-function can achieve this, but I need to test it.
LT
LT(layer, kc) - momentarily activates layer when held, and sends kc when tapped. Only supports layers 0-15.
Not sure I understand what this one does, will read more later.
The text was updated successfully, but these errors were encountered:
(storing my TODOs and thought processes in the issues)
Looking at the QMK Layers documentation, karaml has ways to simulate the following:
MO(layer)
- momentarily activates layer. As soon as you let go of the key, the layer is deactivated./layer/
in the second positionTG(layer)
- toggles layer, activating it if it's inactive and vice versa/layer/
in the first positionThe following can be achieved but in a hacky messy way or are not possible atm:
One-Shot Layer
OSL(layer)
- momentarily activates layer until the next key is pressed. See One Shot Keys for details and additional functionality.In Karaml:
We could do something like automatically duplicate the entire
/git/
layer in a/git_OSL/
and add thevar()
event, and haveOSL(git)
activate/git_OSL/
instead of/git/
, but as far as the configuration is concerned it just looks like editing the/git/
layer.Tap-Toggle
TT(layer)
- Layer Tap-Toggle. If you hold the key down, layer is activated, and then is de-activated when you let go (like MO). If you repeatedly tap it, the layer will be toggled on or off (like TG). It needs 5 taps by default, but you can change this by defining TAPPING_TOGGLE -- for example, #define TAPPING_TOGGLE 2 to toggle on just two taps.Needing multiple taps to activate a layer would be a nightmare (you'd need to create a layer that measures each tap) and then, since I have yet to implement to_delayed_action, there's no time-out to reset the count.
Here's what it looks like with just two taps:
Translation:
From base layer, if
j
is held,/target/
is turned on, and then off on release. If it's tapped,j
turns on the/helper/
layer. From the helper layer, a secondj
tap turns on the/target/
layer and turns off the/helper/
layer. A thirdj
tap turns/target/
off.But this locks you out of repeated keypresses in the base layer, so I would set these up in the
/nav/
layer instead. I think the mental overhead is still acceptable at this point, so long as you're ok with two-tap activation.The karaml-friendly way would be to allow this:
The reason this doesn't work now is because setting a
/layer/
in the second position automatically registers a{set_variable: { name: layer_name, value: 0} }
map in theto_after_key_up
nested dictionary. So whether you tap or hold, the layer gets switched off when the key is released. Bad oversight on my part. More bubblegum code can probably fix this.TO (toggle off?) layer
This seems doable - store a list of all layers before creating the translated-mappings and with a special-event/pseudo function, add all the necessary
set_variable
events, e.g.to(layer_name)
.Default Layer
This one likely isn't possible without a rewrite (which I'd like to do someday)
Layer-Mod
I think the same thing can be achieved with a combination of
sticky()
andvar()
with relatively little mess? So maybe a new pseudo-function can achieve this, but I need to test it.LT
Not sure I understand what this one does, will read more later.
The text was updated successfully, but these errors were encountered: