New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflict with Qukeys #1

Closed
tiltowait opened this Issue Jan 10, 2019 · 5 comments

Comments

Projects
None yet
2 participants
@tiltowait
Copy link
Owner

tiltowait commented Jan 10, 2019

If a modifier is invoked via the Qukeys plugin, it will break shifting rules. My suspicion is that keyToggledOn() is being called, but not keyToggledOff(), meaning num_modifiers_on isn't being decremented back to zero.

Steps to reproduce:

  1. Configure a key in Qukeys to invoke a modifier (such as Key_RightAlt).
  2. Hold that key down, invoking the modifier, then release.
  3. Type an uppercase character using the shift on the same side as that key

Expected result: No character outputted.
Actual result: The uppercase character is outputted. Furthermore, after that point, the shifting rules will no longer apply.

@tiltowait tiltowait changed the title Plugin will stop working after some time Conflict with Qukeys Jan 10, 2019

@tiltowait tiltowait self-assigned this Jan 10, 2019

@tiltowait tiltowait closed this in 8069990 Jan 10, 2019

@tiltowait tiltowait added the bug label Jan 10, 2019

tiltowait added a commit that referenced this issue Jan 10, 2019

@tiltowait

This comment has been minimized.

Copy link
Owner

tiltowait commented Jan 10, 2019

8069990 contained a regression that broke the functionality of ignoring shifting rules while holding modifier keys. Reopening.

@tiltowait tiltowait reopened this Jan 10, 2019

@algernon

This comment has been minimized.

Copy link

algernon commented Jan 10, 2019

What if you put ProperShifting in front of Qukeys in hour KALEIDOSCOPE_INIT_PLUGINS()? Does that help? On second thought, no, it won't.

I guess you could track shift state some other way, rather than looking at keycodes (because those will break with SpaceCadet and OneShot too). I think we have an example of that somewhere, I'll dig it up in a bit.

@algernon

This comment has been minimized.

Copy link

algernon commented Jan 10, 2019

Ok, so we have kaleidoscope::hid::isModifierKeyActive(). So instead of keeping track of whether shift was pressed or not, and which one, you could just use kaleidoscope::hid::isModifierKeyActive(Key_LeftShift) to see if its active.

@tiltowait

This comment has been minimized.

Copy link
Owner

tiltowait commented Jan 11, 2019

Ok, so we have kaleidoscope::hid::isModifierKeyActive(). So instead of keeping track of whether shift was pressed or not, and which one, you could just use kaleidoscope::hid::isModifierKeyActive(Key_LeftShift) to see if its active.

I'll give that a try.

On some reading, the same source file that has kaleidoscope::hid::isModifierKeyActive() also has an anonymous namespace with a function, isModifierKey(). Because it's in an anonymous namespace, I can't use it in my plugin, but would there be any problem with copying that function over to my own code? It's a much cleaner, more efficient way of testing if a key is a modifier than what I currently have.

@tiltowait

This comment has been minimized.

Copy link
Owner

tiltowait commented Jan 11, 2019

[... ]you could just use kaleidoscope::hid::isModifierKeyActive(Key_LeftShift) to see if its active.

After a bunch of testing ... I'm not sure isModifierKeyActive(Key_LeftShift) actually works. ca84268 has my current attempt.

@tiltowait tiltowait closed this in f1676a3 Jan 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment