Qukeys enhancements

(Florent Nicoulaud) #9

I’ve been testing PR 24 for quite some time now but it’s still not satisfactory.
I will try the new PR 35 so that I can find the correct grace period for my use.
I’ll give you some feedback when I have tested it.

(Florent Nicoulaud) #10

@merlin Do you have any idea what is the default grace period for ‘normal’ keys ? So that I could configure Qukeys to have the same period. This way, my qukeys will behave the same way normal keys do.

Thank you.

(Michael Richters) #11

There’s no need for a “grace period” for normal keys, because they start sending their keycodes as soon as the keyswitch activates. A qukey doesn’t send its keycode until either it or a subsequently-pressed key is released — which is fundamental to how they work.

For normal keys, as long as the modifier is pressed first, the order of key release doesn’t matter, because the OS suppresses repeats for ~½ second. When you type shift+s, but release shift slightly before s, this means you only get S, not Ss.

You can increase the qukeys grace period to allow for sloppiness in release order, but if you make it too big (100ms, perhaps), and you type fast, you may end up getting the opposite problem: unintended modifiers. There is fundamentally no way to guarantee that you’ll always get what you want from a qukey if you both type very fast and release modifiers before the keys you intend to modify.

(Florent Nicoulaud) #12

Thank you for the very cool explanation :slight_smile:
I guess you pointed right at my flaw, I must have the bad habit of releasing my modifier key before the modified key, that’s why I’m having difficulties with my modifiers on qukeys…

(Michael Richters) #13

Whether or not that’s a bad habit is a matter of opinion. After all, it works perfectly well on any “normal” keyboard.

If you sometimes get primary (printable) keycodes when you intend alternate (modifier) keys, you can increase the grace period timeout. If you sometimes get alternate keycodes when you intend primary keycodes, you can decrease that timeout. If, without changing the timeout value, you sometimes get both kinds of unintended keycodes, your only recourse is to change your habits, unfortunately.

It would be great if the keyboard firmware could read our minds to know what we intend, but if it could do that, we wouldn’t need the keys. :wink:

(Michael Richters) #14

There is actually one more thing that I can do that might help. I have had a request to allow per-key grace period configuration, which I have a plan to implement. So if a global grace period doesn’t work because you get both types of errors, but only one type of error on any given key, I do have a solution, but it hasn’t been implemented yet.

(Jordihs) #15

Hi Michael. I have a question about Qukeys: Can you trigger a macro, or a specific unicode input with the plugin?
I will be using a spanish keyboard layout in the OS and I’d like to trigger characters such as { } [ ] á é.
The accented vowels in this layout require pressing the ´ and then the desired key. Other symbols are triggered by holding right alt + some key.
Reading the docs, seems you can only specify a single keycode. So in principle this is not feasible with the plugin as-is. Or can you do this, for example?

kaleidoscope::Qukey(0, 2, 1, M(MACRO_ACCENT_A))

Otherwise, I am thinking of a workaround but I have no idea about its feasibility. Suppose I created my own keycode with an otherwise unused value:
#define Key_a_tilde 0xfe

And then I map that in qukeys:
kaleidoscope::Qukey(0, 2, 1, Key_a_tilde)

And then somehow I create a listener (still a noob here!) that captures my fake keycode and triggers a unicode character with no need to use a macro.

Does any approach work? Any alternative ideas?
Thanks for reading!

(Michael Richters) #16

Yes, you should be able to define both the primary and alternate keycodes as any keycode whatsoever, including macros, if you use the full Qukeys definition (like your example). With DualUse definitions in the keymap, you’re much more limited.

(Jordihs) #17

Thanks a lot. I’m assuming that you meant that this would work, right?

(Michael Richters) #18

Yes, that’s what I meant. Typing those alternate characters might feel a bit unnatural that way, though, because you’ll have to hold the key down long enough to trigger the timeout. You might want to push the timeout to a smaller value to make it more convenient, depending on how quickly you normally tap keys while typing. 100 ms might be too short, but it might work.

(Jordihs) #19

Thanks for the insights. I still don’t have the keyboardio but programming and tuning will likely be a lot of trial and error. Good tip about timeouts though. It must hit the sweet spot where it pays off compared to the two separate keypresses that it normally entails to type a vowel with a tilde.

(Jordihs) #20

Hi @merlin, I am having a compile issue with Qukeys. I am quite certain that I am up to date since I just got started today with programming, so I have pulled everything today from git. I am a coder but have no knowledge of C++.
The only thing I changed from the user guide is that I put the code at Arduino\hardware\keyboardio\avr\libraries, and with the include and the call to use &Qukeys it all compiles normally. However, I do have an issue whenever I include definitions. I tried relocating to different points in the source file, but every time I get the same error:

Qukeys.h:135:31: error: expected unqualified-id before ‘{’ token
#define QUKEYS(qukey_defs…) { \

Model01-Firmware.ino:237:1: note: in expansion of macro ‘QUKEYS’

I have tried removing my own definitions and copy pasted the example in the readme.md from your project, but it happens just the same. Do you have any advice on how to resolve this?

Here is my ino file, in case you want to take a look:
Model01-Firmware.ino (17.5 KB)

Note: I am working with the Arduino IDE on windows 10.

Thanks in advance!

(Michael Richters) #21

Sorry about that; I botched that macro definition a bit. It will work if you put it inside the setup() function, but for some reason the anonymous namespace block doesn’t work.

(Jordihs) #22

Thanks a lot, it’s working now. By the way, I am going to remap only the thumb keys and I kind of guesstimated their location. This is supposed to have effect on the first, third and fourth thumb keys:

    kaleidoscope::Qukey(0, 4, 0, M(ABRE_BLOQUE)),       // Alt - {
    kaleidoscope::Qukey(0, 4, 2, M(ABRE_PARENTESIS)),   // shift - (
    kaleidoscope::Qukey(0, 4, 3, M(ABRE_ARRAY)),        // Ctrl - [
    kaleidoscope::Qukey(1, 4, 0, M(CIERRA_BLOQUE)),     // Alt - {
    kaleidoscope::Qukey(1, 4, 2, M(CIERRA_PARENTESIS)), // shift - (
    kaleidoscope::Qukey(1, 4, 3, M(CIERRA_ARRAY)),      // Ctrl - [

Does it seem right to you? I guessed the parameters are (layer, row,col,key) as per the example. I wish I could just test and fix on the keyboardio but as I said, mine is yet to arrive.

(Michael Richters) #23

You’re right about what the parameters mean, but unfortunately, the thumb keys aren’t in row 4, because there is no row 4. The left side thumb keys are column 7, and the right side ones are column 8. Row 0 on each side is the innermost key, and row 3 is the outermost key (closest to you, furthest from the finger keys).

So from left to right, they’re R0C7, R1C7, R2C7, R3C7 on the left side, and R3C8, R2C8, R1C8, R0C8 on the right side.

Keyboard layout for Qukeys?
(Jordihs) #24

Thanks for the tip. I ended up with this:

kaleidoscope::Qukey(0, 0, 7, M(ABRE_BLOQUE)),       // Alt - {
kaleidoscope::Qukey(0, 2, 7, M(ABRE_PARENTESIS)),   // shift - (
kaleidoscope::Qukey(0, 3, 7, M(ABRE_ARRAY)),        // Ctrl - [

kaleidoscope::Qukey(0, 3, 8, M(CIERRA_BLOQUE)),     // Alt - {
kaleidoscope::Qukey(0, 2, 8, M(CIERRA_PARENTESIS)), // shift - (
kaleidoscope::Qukey(0, 0, 8, M(CIERRA_ARRAY)),      // Ctrl - [

Note that in the right hand side mappings I had set layer to one previously but seems to me that they should be all layer 0. (The intent is to open/close parens and brackets with thumb keys while in the main layer)

(Michael Richters) #25

For clarity, you could use the name of the layer (from the keymap enum) — e.g. QWERTY — instead of the number in the Qukey definition.

(Jordihs) #26

Awesome, thanks a lot!

(Dane Summers) #27

I’m curious about mapping mouse scroll keys…I’d like to do something like ‘fn-w’ is Key_mouseUp (the default), and ‘fn-shift-w’ is Key_mouseScrollUp (and similar mappings for scrolldown). At the moment I just map the scroll keys to unused Fn layer keys. Is that something doable with QuKeys?

(Michael Richters) #28

Using full Qukey definitions, mouse keys should work as both primary and alternate keys. I haven’t tested this specific case, but as long as the Qukeys plugin is ahead of the MouseKeys plugin in the processing order, it should work.