I used the DualUse plugin to place the Shift key on the A and semicolon keys. I found it very comfortable to type with the Shift keys directly under my pinkies… until I tried to type a capital A, which was impossible. Pressing the right Shift with A does not generate a capital A, but instead apparently actives the left Shift function of the A. I would have expected the DualUse functionality to only activate Shift if that is the key that is pressed first and then some other key, but not if I press another key and then the DualUse key.
I really can’t find a use case where the current functionality would be desired, because it seems there is no way I can use the Shift functionality in the case where another key is pressed first. For example, holding down the H key and the pressing down the DualUse Shift/A key, does not generate a captial H, but a lower case H (and nothing else). I would want to generate a lower case H and an lower case A.
To summarize, I think DualUse should be changed/fixed, so that the modifier function is only activated when the DualUse key is pressed first and then some other key, but not when some other key is pressed first and then the DualUse key.
Ok, I found a use case where you would want to active the DualUse Shift when some other key is pressed first. For example, if you want to cycle open apps in Windows in reverse, then you might want to press Alt-Shift-Tab. Then you want Shift to active, and not the non-modifier key. There may be other similar uses cases, but still can’t think of any where the first key would be non-modifier, and then the DualUse key.
Another somewhat relate issue, is that it happens all too easy that I have the DualUse key not fully released up when I go on to the next key that I don’t want to combine. As an example if I have DualUse Shift/A, and want to type lower case A, lower case J, then I quite often get a capital J, since the A key is apparently not fully released when I start pressing the J key. This could be solved by not using the Shift functionality if the DualUse key is released before the second pressed key. I can understand that not everybody would like it to behave as I suggest, but it could be configurable.
To clarify with an example again, what I would want:
I have DualUse Shift/A configured
I press A, press J, release A, at this point prints ‘aj’
I press A, press J, release J, at this point prints ‘J’
You should try using the Qukeys plugin instead of DualUse; it should work as a drop-in replacement for DualUse now, and addresses many of the shortcomings of DualUse.
As soon as I use() Quekeys, but not using any of it’s features, my keyboard quickly gets stuck in the function layer. I have nothing special in my config, no other plugins than the ones in the default layout, just a few keys thrown around, and a few plugins from the default removed.
I can’t of course be fully sure it’s Quekeys causing this, but I tried twice to remove the Quekeys plugin and had no problem, and twice added it and pretty immediately had the issue.
I’m pretty sure you’re just not doing the release quick enough. If you hold a qukey long enough (default = 250ms), it starts sending its alternate keycode (in this case, Key_LeftShift). If you want, you can test it out by configuring a longer timeout by adding this line somewhere in your sketch’s setup() function:
Qukeys.setTimeout(1000);
That will change the timeout to 1 full second, which should be plenty long enough to deliberately press and release keys without having to rush.
If you try that, and still see something fishy, please let me know here, or submit an issue on GitHub about it. Thanks for trying it out!
I should add that the reason that timeout exists is so that the alternate (i.e. modifier) keycodes can be used in combination with external pointing devices. It should be set to a value that’s big enough that it’s longer than your longest “tap” duration, but short enough that you don’t feel you have to wait for it to take effect before (for example) shift-clicking with a mouse.
250ms is probably more conservative than most people need, but it seemed like a fairly safe number to start with. I would be happy to adjust the default if people find that they get errors in either direction, but I made it configurable so you people with different use cases can adjust it themselves. You could even use a macro to switch between long and short values, if you want. Come to think of it, that would be useful for debugging…
You are right, the plugin works perfectly! I was releasing the keys very slowly to test it out.
Now it’s just that the function layer gets stuck. It seems to get stuck immediately. I pressed down and released the function key without pressing any other key. After this the keyboard was locked in the function layer, and I found no way of getting out of it.
Tested it, and I can’t reproduce the problem anymore. Thanks!
I think it is really nice to have the Shift keys on the A and semicolon. At least with some 10 minutes test typing. Tomorrow it will get some production testing.
I put shift keys under my index fingers, control under middle fingers, alt under ring fingers, and gui under pinkies. I use shift the most, so I put it under a fingertip that doesn’t get sore from overuse like my pinkie does on occasion.
I…haven’t really tried to learn to type on it yet. I’m being very deliberate and cautious because I want to learn a different, completely custom layout on my Model01 in order to best avoid clobbering my training for typing on normal QWERTY keyboards. Parts of the keymap that I want are still not possible with Kaleidoscope, and I don’t want to make a serious attempt at it until I’ve got my keymap really set up.
Qukeys was one part, and the testing that I’ve done has convinced me that it’s at least worth a try, especially because of the convenience and speed of chording multiple modifiers with fingers on the home row, but I’m not convinced that I’ll want those to be my only modifiers, so I still tentatively have thumb key modifiers. I’ve definitely been thinking about using them for other purposes (maybe layer shifts), but I don’t have specific plans yet.
You’re very devoted! I’ve put in a lot of time into my own layout as well, but not as much as you seem to have.
One thing you said that stood out to me as a potential danger is that you want to continue typing on normal keyboards, but you are also changing the behavior of homerow keys. I can type Colemak on a keyboard and QWERTY on a phone without any issue because the two devices use completely different motions. But there’s not much difference between typing alpha keys on Keyboardio and a normal keyboard… you might find yourself reflexively typing a lot of Fs and Js on a normal keyboard.
That’s a distinct possibility, of course. But the Model01 feels extremely different to my Model M — so much so that I think it will work. It’s not as different as the “keyboard” I use on Aldroid devices (MessagEase), though…