Hello I’m trying to understand the purpose of the release delay option added to Qukeys. Tried searching these forums but didn’t get any result. Can @merlin or anyone else help?
Thanks!
I find that in fast chording my modifier doesn’t get sent at all but I’m wary of decreasing the quantum threshold (
) to avoid unintentional activation. Will this extra option help me?
Without the release delay, the order of key release determines which Key value will be used for the qukey. This is probably clearest with an example. The two keys in these examples are a plain Key_A (A) and a qukey with primary value Key_Q and alternate value Key_LeftShift (Q):
Alternate keycode example:
- Q down
- A down
- A up
- output:
shift+A
Primary keycode example:
- Q down
- A down
- Q up
- output:
qa
With the release delay, there’s no change in the first case, but in the second case the second case has two possibilities depending on what happens next:
- Q down
- A down
- Q up
- time t elapses
- A up
If t is less than the release delay, Qukeys treats the two release events as if they were detected in the other order, and the output will be A after step 5. If the release delay times out, the output will be qa after step 4.
The release delay’s purpose is to accommodate users who are in the habit of releasing modifiers and the keys they modify simultaneously. Kaleidoscope will always process one of the release events first, even if they occur during the same scan cycle, so this gives you a way to get the result you want even if the key releases are detected in the other order.
It’s best to use a small value, such as 20ms — anything longer and you’ll risk getting errors in the other direction, especially if you type fast. The release delay is not likely to work for users who want to intentionally roll over from a modifier to another key, releasing the modifier noticeably before the other key.
Does that help?
3 Likes
Hi! How do you get that boxed display for the keys on this forum software?
<kbd>X</kbd>
1 Like
Hi Michael,
Firstly, Qukey is amazing. I love having modifers on my home row. The big thing is it frees up the thumb keys to be all the common things you would otherwise have to reach for. I think if more people tried it they would realize it’s the one true way.
I have a ShiftToLayer qukey. If I set relase delay (using 50ms to help with reproducing) and use a rollover motion, after all keys are released the layer is still selected.
Also I noticed LT(FUNCTION, RightParen) gives you zeros instead of parens.
Sorry for the delay; I’ve been too busy with other things to keep up here lately.
That’s interesting. If you could submit an issue against Kaleidoscope with specific details, that would be helpful. I’ll try to reproduce it, regardless, when I find the time, and then I’ll see if I can work out a fix.
From memory (I’m rusty, so I could be wrong), the LT() macro can’t encode modified keys, because the high byte is used to record which layer is switched to, meaning it can’t also be used to apply mods, so this is unfortunate, but expected behaviour. A full Qukey object definition does not have this limitation.
I’m very pleased to hear that home-row qukeys are working well for you! With some luck, I hope to get that bug fixed in the next week.
Thank so much for looking at this.
submit an issue against Kaleidoscope with specific details
I couldn’t figure out where the right place to do this is. The Kaleidoscope-Qukeys project is in archive mode so issues can’t be added there. Do you want me to open an issue on Kaleidoscope?
the
LT()macro can’t encode modified keys… A fullQukeyobject definition does not have this limitation.
Yes, the regular qukey mechanism works fine for modified keys.
Yes, please. Many plugins have been merged into the Kaleidoscope repo not too long ago, Qukeys being one of them. Opening an issue against Kaleidoscope is the right thing - and in general, when in doubt, open it against Kaleidoscope. If that’s not the right place, we’ll transfer the ticket. 
So I had a Qukey with a leader key when tapped and shift when held, and it worked more or less exactly as desired. I have since replaced the shift key with a ShiftToLayer(SHIFT) when held, with the same macro and the SHIFT layer being my solution to wanting to do things shapeshifter and topsy turvy are not capable of (and avoiding their bugs).
For some reason or another, that ShiftToLayer key often gets locked to that SHIFT layer, which I can fix by using that key again. Is there anything going on with delays and such that would be making the layers stick in that way?
There is a PR open that fixes recently-reported Qukeys layer-shift bugs. Kaleidoscope#505 should fix the problem of layers getting stuck on when using ShiftToLayer() with Qukeys.
1 Like
Having tested for a fair while, I will tentatively say that has fixed my issue and brought my keyboardio experience significantly closer to my end goal ideal! Thank you!
2 Likes