[LayerLock] Ignores Toggled Layers? Only works on highest layer?

[iamdanielv]

While playing with the Layer Lock library, I found that it is not working as I expected for layers that were toggled.

Proposal / Question 1:

I see in the code that it handles MO and TO which work great, but any time I toggle a layer, it doesn't consider it locked. I am thinking this is done on purpose, but wanted to propose that toggled layers should be considered locked. By doing this, we can use the layer lock key to unlock that layer, otherwise the layer lock key has to be pressed twice for that layer - the first time it locks it, which is effectively a no-op since it was already turned on.

I was able to get the desired effect by adding:

bool process_layer_lock(uint16_t keycode, keyrecord_t* record, uint16_t lock_keycode) {
// .... code removed to show new stuff only
case QK_TOGGLE_LAYER ... QK_TOGGLE_LAYER_MAX: // `TG(layer)` keys.
     if (record->event.pressed) { // On press, toggle the lock
          layer_lock_invert(QK_TOGGLE_LAYER_GET_LAYER(keycode));
      }
      return false;
break;

Proposal / Question 2:

That got me thinking about the other part of the code:

if (keycode == lock_keycode) {
        if (record->event.pressed) { // The layer lock key was pressed.
            layer_lock_invert(get_highest_layer(layer_state));
        }
        return false;
}

this code only considers the highest layer, not the layer from which the key came.

Scenario 1: By considering the layer that sent the lock_keycode, we could have multiple layer lock keys in different locations on different layers and selectively lock / unlock different layers.

Scenario 2: This would also work if we use the same row and column on multiple layers, only considering the highest layer since that would match the row and column.

I was able to get functionality by changing the above code to:

if (keycode == lock_keycode) {
    if (record->event.pressed) { // The layer lock key was pressed.
        //  we need to determine what layer we are on, and then change current state
        uint8_t current_layer = layer_switch_get_layer(record->event.key);

        // original
        // layer_lock_invert(get_highest_layer(layer_state));

        // DV edit
        layer_lock_invert(current_layer);
    }
    return false;
}

I'm still playing with the code, but it seems to give more flexibility. What do you think? Is there value in adding those features?

[getreuer]

Any time I toggle a layer, it doesn't consider it locked. I am thinking this is done on purpose, but wanted to propose that toggled layers should be considered locked.

@iamdanielv this is a nice idea, thanks for the suggestion! You're right that layer-toggle TG keys were excluded on purpose, or more accurately, I hadn't thought of how Layer Lock could be beneficial with TG keys, so it ignores them. You're right though that TG keys do work conceptually like locking the layer, and as in your example the layer lock key could work to toggle off the layer. It's satisfying when features integrate in a predictable way like that.

The QMK maintainers usually push to look for a way of applying existing features where possible over introducing new behavior. From that mindset, I'd say the "layer lock key has to be pressed twice" problem is solvable by placing a TG key at that position instead of the layer lock key. This way, pressing the TG once turns off the layer. Or am I missing the point? Let me know if that's not a full solution or if there's additional value to having Layer Lock interoperate with layer toggles.

[iamdanielv]

This way, pressing the TG once turns off the layer. Or am I missing the point? Let me know if that's not a full solution or if there's additional value to having Layer Lock interoperate with layer toggles.

Think for example using a 60% keyboard without arrows.

Toggle Arrows / Layer lock

I have two ways of getting arrows
Way 1: Toggle the ARROW Layer from a KBD_CTL layer -- this works without layer lock
Temporarily switch to "Keyboard Control" Layer with MO(KBD_CTL) that has the toggle button for toggle an "arrows layer". This is how I was enabling the arrow layer before layer lock.

Way 2: Temporarily turn on the layer with MO(ARROW), then use layer lock to lock/unlock that layer
I'm playing around with only temporarily enabling the ARROW layer, then using the layer lock. It would be nice to have the same layer lock key unlock the ARROW layer that was "locked" with the toggle. This would remove the need to have to go into the KBD_CTL layer to toggle the ARROW layer back off. The ARROW layer would have a layer lock in a specific place just used for ARROW lock -- in my case I am using right alt.

I also have a Home Row Mods Layer -- I toggle this on and off when I want to use a "regular" typing experience vs "Home Row Mod" enabled. This is using Left Shift - Layer lock on double tap, shift otherwise

From proposal / question 2 (Layer Aware Lock):

If the layer lock is not layer aware, it can turn the ARROW key layer off when I just want to turn off the Home Row Mods Layer. Since it just looks at the highest layer

Thanks for your insight! I'm really enjoying playing with different features etc on my little keyboard. This is more a for fun / hobby rather than a strict NEED. But, I think some of these ideas might be helpful.

[iamdanielv]

If it helps, here is a condensed/simplified snapshot of my keymap, I removed a bunch of keys to focus on the important bits:

    [BASE_LYR] = LAYOUT_all(
       KC_ESC,    KC_1,       KC_4,      KC_5,      KC_6,         KC_9,      KC_0,     KC_MINS,  KC_EQL,   KC_BSPC,
       KC_TAB,    KC_Q,       KC_R,      KC_T,      KC_Y,         KC_O,      KC_P,     KC_LBRC,  KC_RBRC,  KC_BSLS,
       MO_CAPS,   KC_A,       KC_F,      KC_G,      KC_H,         KC_L,      KC_SCLN,  KC_QUOT,            MY_ENT,
       KC_LSFT,   KC_Z,       KC_V,      KC_B,      KC_N,         KC_DOT,    KC_SLSH,            UP_RSFT,
       KC_LCTL,   KC_LGUI,    KC_SPC,    KC_SPC,    KC_MUTE,      ARWS_RALT, MO(KBD_CTL),KC_APP,            RCTL_RGT
    ),
    [HRM_BASE_LYR] =  LAYOUT_all(
       MY_GRV,    _______,    _______,   _______,   _______,      _______,   _______,   _______, _______,  _______,
       _______,   _______,    _______,   _______,   _______,      _______,   _______,   _______, _______,  _______,
       _______,   GUI_A,      CTL_F,     CTLS_G,    _______,      ALT_L,     _______,   _______,          _______,
       LSFT_LLCK, _______,    _______,   _______,   _______,      _______,   _______,            _______,
       _______,   _______,    _______,   _______,   _______,      _______,   _______,   _______,           _______
    ),
    [KBD_CTL] = LAYOUT_all(
       _______,   _______,    _______,   _______,   _______,      _______,   _______,  _______,  _______,  _______,
       _______,   TD_KB_RST   _______,   _______,   _______,      _______,   _______,  _______,  _______,  _______,
       _______,   _______,    _______,   _______,   _______,      _______,   _______,  _______,            _______,
       _______,   TD_KB_CLR   _______,   _______,   NK_TOGG,      _______,   TG_HRM,             TG_W_FN,
       _______,   _______,    _______,   _______,   _______,      TG_ARWS,   _______,  _______,             DVLLOCK
    ),
    [ARROWS] =  LAYOUT_all(
       _______,   _______,    _______,   _______,   _______,      _______,   _______,   KC_VOLD, KC_VOLU,  KBCTL_BSPC,
       _______,   _______,    _______,   _______,   _______,      _______,   _______,   _______, _______,  _______,
       _______,   _______,    _______,   _______,   _______,      _______,   _______,   _______,           _______,
       _______,   _______,    _______,   _______,   _______,      _______,   _______,            KC_UP,
       _______,   _______,    _______,   _______,   _______,      DVLLOCK,   KC_LEFT,   KC_DOWN,           KC_RIGHT
    )

ARWS_RALT is MO(ARROWS) on hold, alt on tap
TG_ARWS - toggles the ARROWS layer
DVLLOCK - keycode I am using for my experiments
LSFT_LLCK - Layer lock on double tap, otherwise left shift
KBCTL_BSPC -- since I lose the MO(KBD_CTL) when I enable the arrows, I had to move it to double duty on the BSPC key, but you can probably ignore that one for now.

I had to remove a bunch of keys to make it easier to understand and changed some of the names. It might be a little different from my actual keymap, but it should get the point across.