Conversation
* Allow tap/press/release of a given key position within the Zephyr shell.
Add a new "runtime combo" concept. Much like reserved layers for keymaps, users can add any number of additional combos with `status = "reserved"` to add extra combos that can be created at runtime. Persistance of runtime combos to the settings subsystem will be added in a follow-up commit. Runtime combos are identified by an "id" value, since they may be sorted based on runtime changes to preserve the fast combo expectations when keys are pressed.
For testing and diagnosis, add a new `combos` shell command that is used to view/add/remove/edit runtime combos within the Zephyr shell.
Add a combo subsystem for interactions with the runtime combo functionality, including get/add/remove/update operations.
nmunnich
left a comment
nmunnich
left a comment
There was a problem hiding this comment.
Good refactoring.
At a skim of the actual runtime support commits, my main concerns would be around the organisation of the extra bits to support runtime. I think as-is if we continue like this all of our files will become even more annoying to read and understand.
I also wonder if there's some abstraction/metadata-based approach we could use to provide editing of the settings for all behaviors, and squint a bit to equate combo_cfg to behavior_config. If we want to allow out-of-tree behaviors to be customisable with Studio then we'd definitely need some approach like that, and we could probably reuse most of that to add combo customisation.
| * @retval false if there are changes. | ||
| */ | ||
| int zmk_keymap_check_unsaved_changes(void); | ||
| bool zmk_keymap_check_unsaved_changes(void); |
There was a problem hiding this comment.
has_unsaved_changes seems like a better naming convention, with the boolean returns inverted.
Fair. Let me exploring moving the runtime bits into a separate file for at least some clarity/organization.
Yeah, a generic "editable object" metadata approach has been on my mind for a while, to support behavior editing, and could be used for combos as well. I envision it a layer more abstract than just editing behaviors, but any singleton item (e.g. "lighting settings" or "EC Settings") or collections (e.g. combos or hold-taps/behavior instances). I'm definitely open to playing with that, with combos as a first test case. |
2 participants
Draft for now, just to kickstart discussions.
Like with keymap layers, combos assumes you crease some reserved combos, and you can set the max number of supported "key positions" for combos by setting key positions on one of the reserved combos.
No UI support, but you can test with electronicmaterialsoffice/zmk-studio-cli#2 for now.
Lots more testing needed, just a start for discussion on the design.
PR check-list