qmk/qmk_firmware

Proper customization at the keymap level is impossible due to _user() functions either being handled incorrectly or not returning a bool.

Open

#8.246 geöffnet am 25. Feb. 2020

Auf GitHub ansehen
 (7 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C (43.867 Forks)batch import
discussiondocumentationhelp wantedquestion

Repository-Metriken

Stars
 (20.368 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 20T 9h) (27 gemergte PRs in 30 T)

Beschreibung

Incorrect handling of bool _user() functions

This is the advice given when writing a custom _kb() function, straight from the docs:

wiki

For process_record_kb() for example, that description would be roughly equal to this code structure:

bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
    if (!process_record_user(keycode, record)) {
        return false;
    }
    // Do _kb stuff only if process_record_user() didn't already handle the key event.
}

Yet all implementations I could find of process_record_kb() look like this:

bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
    // Alway do _kb stuff, and potentially even skip process_record_user() with early return.
    return process_record_user(keycode, record);
}

As a results you have to change code at the keyboard level if you want proper control at the keymap level.

No option of overwriting non-bool _kb() functions

The second part of this (which might even deserve its own issue), is that a lot of _user() and _kb() functions simply don't return a bool, which makes it impossible for the keyboard level to know if the user level already handled that functionality.

This includes things like void encoder_update_kb(), void matrix_init_kb(), void raw_hid_receive_kb(), void matrix_scan_kb() and a bunch more.

Contributor Guide