I used the GUI, I’ll do the git clone to get the newest one, thanks.
It’s working fine, thank you for the help.
And your plugin works like a charm, it’s doing what I’ve been unable to achieve with both SpaceCadet and DualUse !
2 Likes
Fantastic! Thanks for trying it out, and let me know if you have any problems. There are some known compatibility issues (see earlier questions in this thread), but I have a fix for at least one of them in a branch of Kaleidoscope if that becomes a problem for you.
If you feel like sharing, I’m interested in how you’ve configured it, and how fast you type on your Model01.
I’m a former Ergodox / Colemak typist, so I’m quite at ease with the model 01.
I just need to adapt to some new ways / key positions I’m trying out for the occasion of switching from the ergodox to the model 01.
I discovered the dual use keys, which are very interesting, I’m only using them on the thumb keys to have a shift/enter key under both thumbs.
What I was unable to achieve with DualUse and SpaceCadet was to be able to do ctrl+enter or alt+enter with my special shift/enter key. I can confirm that I can now do that with your plugin.
I discovered this morning the Community Intros post, I’ll try to introduce myself other there soon.
2 Likes
Here’s my (simple) config by the way:
QUKEYS(
kaleidoscope::Qukey(0, 2, 7, Key_LeftShift), // Enter/shift
kaleidoscope::Qukey(0, 2, 8, Key_LeftShift) // Enter/shift
)
1 Like
I’ve had a report of undesired behaviour when releasing two keys (one of which is configured as a qukey) simultaneously. I’ve known that if a qukey is pressed, then a subsequent key is pressed, and both are released simultaneously (as far as humans can tell), it will be unpredictable which keycode will be produced by the qukey. When using modifiers, I’m deliberate enough that this is not something that I ever see while interacting normally with a keyboard, but if there is enough call for it, I can add a configurable parameter that will provide a “grace period” for chorded qukey releases. In other words, if a qukey release is detected while at least one other key is pressed, that release (and the decision about which keycode to use) will be deferred until after some short time has passed – say 0-50ms.
This would add a bit of code, and complexity (I’m not really sure how much yet), and it comes with the danger of rollover producing undesired alternate keycodes. It might not be worth the effort, and a second plugin (i.e. SpaceCadet) that does almost the same thing, but defaults to the chorded modifier, might be an easier solution. I’d prefer not to add to the code, but if there’s demand for it, I probably will, so if anyone wants this feature, please comment on it either here or in Qukeys issue #25.
Thank you so much. Being able to map all the modifier in the home row is a game changer 
- especially in combination with the third layer of the NEO layout.
1 Like
Thank you, @merlin, for this fantastic plugin! After some initial difficulties the plugin works like a charm. Exactly what I was searching for.
I use the Qukey to switch to a different layer. I made two mistakes in setting that up which I want to share. Maybe it will prevent other people from making the same mistakes or at least help them in figuring out what is happening:
1.) I configured a Qukey on Layer 0 to switch to Layer 1. On Layer 1 that key had a different meaning. That doesn’t work. The key needs in fact to be “transparent” ("___") (see mistake 2).
2.) I added a layer which didn’t use the particular key but made it Layer 2 at first. In order to not have the key behave in a different manner I masked it (“XXX”). That got me stuck in Layer 2. The solution was easy: Rearange the new layer to be layer 1 and make the key “transparent” ("___")
Here is my very simple configuration:
QUKEYS(
kaleidoscope::Qukey(0, 2, 15, ShiftToLayer(LAYER3LEFT)) // Ä/LAYER3
)
I chose the name “LAYER3LEFT” because it switches to layer3 of the NEO layout but omits the ‘@’ sign which happens to be on the same key as the Qukey. See @rubas post.
1 Like
Hi @merlin,
today I realized that the qukeys work like a charm but I’m unable to type shifted characters. That affects both keys that I’m using with the qukeys plugin. Did anyone else experience something similar. Any idea what might be the issue?
I’m not sure what you mean by “shifted characters”. Can you be more specific?
Sorry. I mean uppercase letters. I have ‘y’ and ‘ä’ as qukeys (which are ‘z’ and ‘’’ printed on the caps) and I can only produce lowercase letters.
I also realized, that when pressing Shift, my qukeys will not work their alternate function any more.
If you send me a link to your sketch, I can probably figure out what’s going on.
I just found it: It seems to be an incompatibility with the OneShot plugin. I configured my Shift-Key to be a OneShot-Key. If I change it back into a “normal” Shift Key I can type uppercase-letters again.
I’ll check if I can workaround that by modifying the order of the plugins.
Sadly the order of plugins doesn’t make a difference.
After reading the code for a while I think I understand what is happening:
The Qukeys plugin directly sends out keyboard-reports therefore bypassing all other plugins on the way.
In order for other plugins to be able to work, the Qukeys-queue would have to be flushed in a different manner.
This is not fully thought through but I imagine the plugin would have to add the keys back to the scan-matrix so that other plugins would be able to see the key, while remembering that this particular key was just released from the queue so it doesn’t register in the Qukeys-plugin again.
When Qukeys sends a report mid-scan, it directly copies the previous keyboard HID report, so if any modifiers were active in the previous report, they still should be when the Qukeys report gets sent. If your explanation is correct, unless I’m wrong about how OneShot works, it’s not a design flaw, but it is a bug in one or the other of the plugins.
Furthermore, it doesn’t bypass the other plugins, it calls handleKeyswitchEvent()… which is maybe why OneShot isn’t working for you. What keys do you have defined, and in what order do you press and release them in order to produce the unintended behaviour?
I think I’ve figured this out. I’ll have a PR ready shortly for you to test, @michael. I admit that I don’t really understand the code for Kaleidoscope-OneShot, but it seems to be a problem of OneShot sending injected events with UNKNOWN_KEYSWITCH_LOCATION that Qukeys wasn’t ignoring.
The PR is ready – it’s Qukeys#36, if you want to give it a try. I was able to reproduce what I think is the bug you were seeing, and this change fixes it for me.
1 Like
Lovely. That works. Thank you for your continuous efforts!
Just out of curiosity: Why are you using a pull request on your own repository?
1 Like