kmk_firmware
kmk_firmware copied to clipboard
KMKfw
add continue-with-module-nr-idx to key processing
This is an approach to make modules with side effects more consistent (related to #495).
At the moment, I think only hold-tap (and it's decendents) and combos profit. Modified keys can be re-inserted into the process_key pipeline after the module that modified them, basically "picking up where they left of". It's not a super clean, automatic thing for all modules (yet), I acknowledge that; but it's a simple enough solution, doesn't break unit-tests or changes too much of the core firmware.
Input from contributors of #495 is of course welcome, especially towards perceived effectivenes.
You're absolutely right. Incidentally that's what I tried first and got tangled up in a terrible, un-working mess, as first implementations go. So I settled for the bare minimum, easyiest solution without disrupting to much of the current code base. Should have been a draft from the start.
Optional side quest since I just thought of it: seems like maybe a good introductory case for #226/#497 too - this would be a new "interface" modules can speak over, and is nice and tightly scoped (read: shouldn't spill over into tons of the other code), so any relevant modules could be type checked against the new interfaces, but everything else left alone?
@klardotsh what's your opinion on this implementation? I'm not used to using type hints in python yet, but it seems like something we may want to insist on for core contributions, bit for bit.
Type hints are on my hint list when I have spare time to actually write actual code. IMHO, that's a massive improvement for everyone. Tooling loves it, tests love it, and reduces confusion. Klardotsh and I seemed to agree that the core should enforce it (talked off platform) IIRC.
Haven't found any other obvious bugs, I think it's good to go. We may want to take a look at all the other modules that issue key events. Maybe some of them want to joint the resume-processing-club.