Closed soraxas closed 2 years ago
IfPrimary / IfSecondary currently uses the advanced secondary role mechanism described an discussed in https://github.com/UltimateHackingKeyboard/firmware/issues/207 / https://github.com/UltimateHackingKeyboard/firmware/pull/326
Long story short, recognition is based on release sequence - in order to activate secondary role, next key has to be released at least <safety gap>
ms before the secondary role key. You probably want to decrease the gap rather than increase it.
For your usecase, I guess you might want to use standard simple strategy. Regarding that, when the PR is accepted in official repository, I plan to connect the macro mechanism to the secondary role driver, and add argument to allow picking one of the two resolution strategies.
Also, I guess you would be fine with the mechanism described in examples - search for ifInterrupted
.
I see! Thanks for the great pointer and explanation of the advanced usage of ifPrimary
/ ifSecondary
. I do agree that for my usecase, ifInterrupted
would probably makes more sense.
Connecting the macro mechanism to the official repo with selectable resolution does sounds interesting! Hopefully this repo can get to merge more features back to the official repo.
I wanted to use the ifPrimary / ifSecondar / resolveSecondary to implements ctrl+esc combo.
However, sometimes when I press the
MacroKey
+otherKey
too quickly,MacroKey
is still being resolved as the primary key (i.e. emitsesc
in my setup) rather than being treated as a secondary key (i.e. emitsctrl
+whatever
)I have initially used the
ifPrimary
/ifSecondar
, and switched toresolveSecondary
to see if the parameters help. Please provide any guideline to me if I am missing something!The following is how I worked around the issue (the
ifPending
command to check if there exists any pending key even when it was resolved as primary key)