feat: Refine behavior_binding_event, nested trans
This PR essentially does multiple things in one commit. These are all quite linked to one another, I wasn't quite able to untangle them from each other.
- Refactors the existing sensor code, making encoder rotational tracking happen outside of behaviors and inside
sensors.c. - Revamps
zmk_behavior_binding_eventso that it is actually a zmk event, i.e. is raised and managed byevent_manager. - Allow the nesting of
&transinside of other behaviors, getting rid ofZMK_BEHAVIOR_TRANSPARENTin the process.
Taking the explanation from #573: We currently have the following events
- position_state_changed
- keycode_state_changed
- layer_state_changed
What is missing from this event flow are behavior bindings. This means they can not be observed like other events.
- position_state_changed
- behavior_binding_event
- keycode_state_changed
- layer_state_changed
- behavior_binding_event
This refactor/feat will allow for much more advanced and elegant handling in the future. My goal is to use this to rework combos a bit further. Nesting &trans is also a benefit that should not be underestimated, it will make things like home-row mods much easier to set up. The sensor refactor should allow further work on that part to be simpler as well.
Needs documentation and lots of testing, particularly around the encoder bits as the tests we have are very rudimentary. There are likely some stylistic bits that could use tidying up as well.
Closes: #573, #532, #2368
PR check-list
- [x] Branch has a clean commit history
- [x] Additional tests are included, if changing behaviors/core code that is testable.
- [x] Proper Copyright + License headers added to applicable files (Generally, we stick to "The ZMK Contributors" for copyrights to help avoid churn when files get edited)
- [x] Pre-commit used to check formatting of files, commit messages, etc.
- [x] Includes any necessary documentation changes.
What documentation changes do you have in mind, besides updating the new behavior guide?
Can you update the PR description and the new behavior docs for the latest changes?
I've moved the behavior_dev and the params into the event now. This allowed for a significant refactoring and simplification of lots of parts. I think writing a behavior has become simpler, but interacting with the behavior queue has become slightly more annoying. Documentation still to come.