Sorry; I didn’t have time to adequately test the rebase after making a change to fix the plugins that were getting values stuck in the keymap. I missed the fact that this caused other problems. I pushed another update just now, and I believe that OneShot is working properly again on #905, though I haven’t testing it with Qukeys (or other plugins in general) yet.
The behaviour as to not working ‘Key_OneShot_Stickify’ and OSL() keys has not changed.
OSL(Ln) as alternate Qukey state still works.
Now the first Layer Ln switched to does not remain sticky any more.
I have observed something new:
When shifting to a higher layer Ln by alternate Qukey state (OSL(Ln))
• the keys bound to e. g. ‘SHIFT(Key_Slash)’ or ‘RALT(Key_8)’ output the unmodified values ‘Key_Slash’ and ‘Key_8’
• a key bound to a macro ‘M(MACRO_LESS_EURO)’ does not output anything
I believe I’ve fixed the problem with Qukeys interfering with other plugins in #905 now; the PR needs another git history overhaul at this point, but it should be much better.
The latest version is great! 
Thank you!
Is it possible to selectively deactivate the ability of a key to cancel the Stickiness set by it’s Qukey alternate value in combination with ‘Key_OneShot_Stickify’?
E. g., I have ‘Shift’ under the index fingers. After having made ‘Shift’ sticky with the left index and ‘Key_OneShot_Stickify’ a subsequent tap with the left index would inadvertently cancel the Stickiness.
1 Like
There is possibly one more thing to sort out with macro/Qukey interference(?):
In layer L0 I have a Qukey with ‘Key_Space’ as first value and ‘OSL(L1)’ as alternate value.
‘Space’ (when tapped) and ‘shift to layer’ (when held) work as expected, except for ‘OSL(L1)’ combined with ‘Key_Escape’ (on layer L1). I only get the ‘Escape’ after having held the Qukey for ~1s; when held shorter, nothing is output. All the other keys on layer L1 get output, even for very short hold times of the ‘Space’ Qukey.
The ‘Escape-OneShot’ plugin is used.
Is Key_Escape the same on both L1 and L0? If so, I’m pretty sure I know what’s going on. I think you’re holding the Qukeys/OSL key long enough to trigger both hold timeouts, one after the other. OneShot doesn’t know the key has been pressed until Qukeys releases it from its queue, and that doesn’t happen until the Qukeys hold timeout has expired (since no other keys have been pressed yet). Then, if you hold the OSL key long enough, its OneShot behaviour times out, and effectively becomes a normal layer-shift key. Since Escape-OneShot suppresses the esc keycode if there are any active OneShot keys, it doesn’t appear to work.
Do you ask if ‘Key_Escape’ is on the same key on layer L0 and L1? No.
I have ‘Key_Escape’ on all layers at the usual position in the lower left corner. And also at position R2C2 on layer L1 (as in the AdNW/Neo layout) which I use most.
Yes, that’s what I meant.
Which L1 escape key are you using in this scenario?
I’m still not sure what the sequence of events is. Here’s what I’m guessing:
- press space (qukey alternate:
OSL(L1)) - wait for Qukeys hold timeout, or possibly longer
- release space
- press esc (the one at
KeyAddr{2, 2}, not the one in the corner)
…and if you hold space for less than ~1s, you see no output on the host computer, but if you hold it pressed for longer than that time, you observe an esc character being sent?
Or is it like this:
- press & hold space
- press & release esc
- release space
…and the output of the keyboard depends on how much time passes between steps 1 & 2?
Either way, I suggest you try it with a plain OSL(L1) key to see if there’s a difference. And since it’s possible that there’s a scan-order dependence, it’s best to do that on the same key where you currently have Key_Space mapped.
Another thing to try is changing the order of OneShot and Escape-OneShot in KALEIDOSCOPE_INIT_PLUGINS().
Sorry for not being clear enough.
In this scenario I use the key at ‘R2C2’. But I have just tested it with the one in the lower left corner (R3C0): the (mis?)behaviour is the same.
I mean the latter sequence with this behaviour:
Currently I have no plain OSL(L1) key — I’ll try this and plugin instantiation order tonight…
I replaced ‘Key_Space’ with ‘OSL(L1)’, deactivated the Qukey for this position and found no difference compared to ‘OSL(L1)’ as alternate value of a Qukey: Escape is only emitted after keeping pressed ‘OSL(L1)’ for ~1s.
This has no effect.
What’s the OneShot hold timeout? That’s probably the threshold you’re seeing.
It is not set explicitly — must be the default value!?
Are you using Kaleidoscope master, or still #905?
I use PR#905.
When I set OneShot.setHoldTimeout(100); the required hold time for ‘OSL()’ seems to be less, but still noticeable. The Space Qukey together with ‘Key_Enter’ e. g. (also on layer L1) does not require any noticeable hold delay for Space.
I will look into this soon. There’s a good chance that I’ve made a small error in Escape-OneShot on that branch; I will let you know if and when I find anything.
I’m certain that this is working as designed. It would be possible to track whether or not the key is physically pressed, but in my opinion it’s not worth the resources it would require just for this. I do have an alternative, however, which is to assign a different key to trigger EscapeOneShot, like this:
EscapeOneShot.setEscapeKey(Key_OneShotEscape);
That dedicates the plugin-specific Key_OneShotEscape (also new in #905) as the key that will cancel active OneShot keys, instead of Key_Escape. Of course, it does require having space for it in your keymap, but if it’s something that’s needed frequently, I would expect that not to be a big problem.
Yes! This works great 
Thank you!
My ‘normal’ Escape is now output as fast as the other layer L1 keys shifted to with ‘OSL(L1)’.
Would it be technically doable to have the ‘Key_OneShot_Stickify’ act as ‘Key_OneShotEscape’ when tapped on it’s own?
Sort of ‘Key_OneShot_Stickify’ being the QuKey alternate value of ‘Key_OneShotEscape’, triggered by an already held modifier…?
When I first read this question, I thought it would be needlessly complex and counterintuitive, but now I’ve reconsidered, and I think it’s quite a sensible thing to do. I can think of a way to implement it without too much overhead.
2 Likes