Qukeys question, adding Shift to PgDn and `-`

First I have to say I think the Model01 is worth every penny. After a couple of weeks of pure frustration trying to get used to it (and almost caving in and posting it for sale) I’ve made a few minor adjustments to the layout and I’m wondering how I ever used another keyboard. The palm fn keys are just genius!

So my contribution to the mutual admiration society aside, I am having an issue with the Qukeys plugin. I’m using it to add a Shift key to the PgDn and -_| because some shifted key combinations were causing me to unknowingly activate the palm fn keys. My checkouts of the Keyboardio firmware repositories are up to date. I can’t seem to get the timings right, so sometimes a Shift - doesn’t register any keypress at all and sometimes the keys I remapped seem to get “stuck” and not do anything until I repeatedly press them. Right now I have it configured as follows:

         //                  l, r, c, alt_keycode
         kaleidoscope::plugin::Qukey(0, 3, 0, Key_LeftShift),  // PgDn/Left Shift 
         kaleidoscope::plugin::Qukey(0, 3, 15, Key_LeftShift),   // _|- / Right Shift
  // Qukeys.setReleaseDelay(10);

Maybe I don’t understand what setTimeout and setReleaseDelay do exactly? Larger values of setTimeout seem to make the shift operation a lot more janky, and smaller values cause the shift to fail and the shifted key just generates it’s non-shifted version. The description of setReleaseDelay in the documentation didn’t seem to apply to the behavior I was experiencing.

Is there a better way to achieve what I’m shooting for? I’d like to add Ctrl to PgUp and '/" also but I want to get this working more reliably first.

Finally, I’m a JetBrains product user, mostly PyCharm, and PyCharm’s default “search everywhere” shortcut is a double-tap on the Shift key. This works with the native Shift key on the Model01, is there any way to get this to work with the remapped Shift? Makes sense if not, so maybe the best approach is to change the keybinding in PyCharm…

I’ll start with the easy one:

Short answer: No.
Long answer: It depends on the length of the timeout you use, the tolerance used by PyCharm, and how accurate and consistent you are when performing a “long double press”. I definitely would not recommend trying it.

Now for the important questions:

Qukeys works by not sending any output for a pressed qukey until either the qukey is released, a subsequently-pressed key is released, or a timeout is reached. Which Key value it uses depends on which of those three events happens first.

setTimeout() sets the length of time (in milliseconds) for a qukey to be held by itself before its state is determined, and a keypress event is sent to the host (assuming its alternate Key value is a keyboard key). This setting mostly exists so that qukeys can be used in combination with other devices (i.e. shift + mouse click).

setReleaseDelay() sets a grace period after a qukey is released so that users who tend to release modifiers and modified keys simultaneously get the desired result more often. With setReleaseDelay(10), if the qukey is released first, it will stay in an undecided state (as if it was still held) for 10ms before taking on its primary value. If a subsequently-pressed key is released in the interim, it will take on its alternate value (in your case, Key_LeftShift) instead.

If you’re seeing small timeout values (e.g. setTimeout(50)) result in primary Key values (i.e. the value in the keymap, usually a printable character), that’s very surprising; I would expect the opposite. When you say it “causes the shift to fail”, is it as if you didn’t press the qukey at all, or are you also getting a keycode from that key?

When you describe the behaviour with large timeout values as “janky”, are you referring to it being used in combination with a mouse? Or in combination with other keys on the same keyboard?

Which keys are getting “stuck” – just the two qukeys you defined?

By Shift -, do you mean you’re holding down pgdn while you tap -? My only hypothesis so far is that your timeout value of 150ms is too low, and that you’re holding down - too long, but I don’t know enough to be sure at this point.

Last, Qukeys has been pretty thoroughly rewritten, but hasn’t yet been merged. If you’re seeing any buggy behaviour in the older version, I recommend trying the new one, which should work substantially better for dealing with rollover issues. It also lets you configure qukeys “backwards” (modifier in keymap, “tap” value in the Qukey definition) for SpaceCadet emulation.

Wow, thanks for the detailed response! If I have time this evening I will experiment with the unmerged rewritten version.

I recommend reading the section on user-visible changes in this comment: