Finer “stickability” control for OneShot

I have just submitted a PR for allowing finer i.e. per-modifier and per-layer control of the “stickability” of one-shot modifiers.

This obviously needs to remove the older boolean controls but doesn’t otherwise (intentionally) change any OneShot behaviour.

Though it is right now working on my keyboard with the following settings:

    OneShot.stickableAllMods(false);
    OneShot.stickableMod(Key_LeftShift, true);
    OneShot.stickableAllLayers(false);
    OneShot.stickableLayer(LYR_NAV, true);

… it probably bears some testing as it is my first code contribution to the firmware involving serious code change.

Many thanks to all the good people here and especially @jesse for KeyboardIO and @algernon for OneShot and more!

1 Like

In some other thread here someone had asked whether such a behaviour was possible which made me realize I had the same need too. I searched for that post to link to it and say thanks for the idea but couldn’t find it. If the person or anyone else knows, please link!

I’d like to add suggestions for a couple additional properties/functionalities to OneShot. I think it would be nice if the OneShot key would stay be active if the next key pressed is pressed again before a “repeat key timeout” (e.g. tapping ctrl once followed by multiple taps of bksp to delete multiple words) or if the next key pressed is held (e.g. tapping ctrl then holding shift while pressing arrows to select entire words).

I also want to continue the appreciation all the work @algernon and @jesse and others are putting into these plugins! For someone like me who knows only how to modify code at a high level, it has been great to have these plugins that make for a keyboard I love to use!

I think this is out of scope for OneShot. It’s already fairly complicated, implementing this would make it even more so. What you can do is double-tap the modifiers you want to be active for longer, press or hold any other key as many times as you wish, and when done, a third tap on the modifier undoes the stickyness. It’s a bit more work, as you have to tap a key twice, and remember to unsticky it (the ActiveModColor plugin helps with that), but it’s much more reliable than a timer-based solution would be.

In other words, to delete multiple words, say, give, you’d do this sequence: Ctrl Ctrl Backspace Backspace Backspace Backspace Backspace Ctrl. Since OneShots do not cancel each other, and you can have multiple ones active at the same time (even multiple sticky ones!) you can even do Ctrl Ctrl Shift Shift Left Left Left Ctrl Shift to select three words to the left. Or you can hold shift, and do Ctrl Ctrl Shift+Left Shift+Left Shift+Left Ctrl to achieve the same thing.

Hope this helps.

It’s great to hear they’re proving useful, thank you!

For my particular keymap, I had thought through this option, as well as other plugins or keymappings to help with the example situations I gave. But as you mention, OneShot sticky functionality creates extra keypresses, and other options over-complicate the number of modifiers or layers.

I didn’t know how hard it might be, but wanted to ask in case it was easy. Thanks for responding to let me know.

I also think your timeout idea is too complex to be practical, but your other idea might not be, and actually strikes me as reasonable. It also seems like it would be less surprising to have the (non-sticky) OneShot modifier stay on until the first subsequently-pressed key is released, rather than to release the OneShot when the next key is released. I think the amount of extra bookkeeping and logic would be minimal (I’m confident that it would be simple in Kaleidoglyph, be less certain about Kaleidoscope).

If the next key pressed after the OneShot isn’t a modifier, I’m not so sure what would be generally less surprising. During normal typing (not games), most operating systems suppress one printable character when the next one is pressed, so keeping the OneShot active while the OS is suppressing the keycode for the first subsequent key might be confusing. That’s a fairly odd thing for a user to do, so maybe the game scenario — where there’s not much difference between modifiers and other keys — is more applicable, and in that case the best thing would be to treat non-modifiers the same as modifiers.