Deprecate KC_LOCK for QK_LOCK (#18796)

This commit is contained in:
Ryan 2022-10-22 01:46:10 +11:00 committed by GitHub
parent b33fc34967
commit 7cbff9d921
Failed to generate hash of commit
58 changed files with 66 additions and 83 deletions

View file

@ -70,7 +70,7 @@ bool process_key_lock(uint16_t *keycode, keyrecord_t *record) {
// reset the state in our map and return false. When the user releases the
// key, the up event will no longer be masked and the OS will observe the
// released key.
// 3. KC_LOCK was just pressed. In this case, we set up the state machine
// 3. QK_LOCK was just pressed. In this case, we set up the state machine
// to watch for the next key down event, and finish processing
// 4. The keycode is below 0xFF, and we are watching for new keys. In this case,
// we will send the key down event to the os, and set the key_state for that
@ -95,20 +95,20 @@ bool process_key_lock(uint16_t *keycode, keyrecord_t *record) {
if (record->event.pressed) {
// Non-standard keycode, reset and return
if (!(IS_STANDARD_KEYCODE(translated_keycode) || translated_keycode == KC_LOCK)) {
if (!(IS_STANDARD_KEYCODE(translated_keycode) || translated_keycode == QK_LOCK)) {
watching = false;
return true;
}
// If we're already watching, turn off the watch.
if (translated_keycode == KC_LOCK) {
if (translated_keycode == QK_LOCK) {
watching = !watching;
return false;
}
if (IS_STANDARD_KEYCODE(translated_keycode)) {
// We check watching first. This is so that in the following scenario, we continue to
// hold the key: KC_LOCK, KC_F, KC_LOCK, KC_F
// hold the key: QK_LOCK, KC_F, QK_LOCK, KC_F
// If we checked in reverse order, we'd end up holding the key pressed after the second
// KC_F press is registered, when the user likely meant to hold F
if (watching) {