DualUse waits for a “timeout” before switching to the secondary use.
I’m looking for an approach where:
So there’s no timeout involved, only a “by itself” or “with others”.
I’m thinking I could achieve this with “MagicCombo”, but writing an entire layer with MagicCombo would be unwieldy.
Any advice? Thanks!
If I understand what you mean, I think you could do something like this by writing a custom event hook that checks if the given key is held down in addition to another key and activate a shift to layer? Basically, write your own plugin, which is obviously not a very helpful answer 
Yeah… C++ isn’t my strong suit. I mostly copy/paste from the examples to put together my .ino files 
if it helps anyone understand, Karabiner calls this behavior: "to_if_alone"
Right, but Karabiner also has a timeout setting for that – "basic.to_if_alone_timeout_milliseconds": 1000 in my config.
Based on my noob-level understanding of how all this stuff works, the keyboard is basically periodically sending time-based snapshots of which keys are pressed at that particular moment – so there’s not really a “by itself” or “with something else”, there’s just “within approximately the same interval, give or take”, or “outside that interval, give or take”. Overall, everything is happening fast enough on human-perceptible timescales that you can effectively treat it as “by itself” or “at the same time”, but on an implementation level, that timeout has to be there.
That makes sense. I guess I’ll just have to keep playing with the time_out then. The thumb keys are so darn convenient that I press the second key too darn fast. 
Yeah, I’m pondering experimenting with reducing it to 800 or so, but I’m also at the point where I need to quit changing things lest I never actually learn to comfortably use it… 8^)
I think the “plugin” you’d have to write would be fairly simple - set a flag when the key is pressed, clear it when released, if another key is pressed while the flag is set, switch to the layer until the next keypress…kind of the opposite of this handy thing I saw someone post on Mastodon.
Thanks, that’s insanely helpful.
You are not the first one to have a timeout-less DualUse desire, so there appears to be a reasonable demand for it.
One of the reasons I didn’t write one such yet, is that there are a few edge cases I couldn’t figure out (I don’t use DualUse myself, that’s probably why). Like, say, you want to use the second behaviour of shifting to a layer, and you hold down this key, then a second or so later, press another key. Without a timeout, how would you prevent Esc from being input? Or is it ok if we get a bit of Esc? Personally, I would find that very frustrating to use, and would prefer if Esc didn’t fire in this case. But I’m unsure how to solve that without a timeout.
@merlin had some thoughts on this, at DualUse#1 and DualUse#7, but I don’t have the mental capacity to think about his ideas deeper.
@algernon would it help if you could “force” the following restrictions?
Those are my only scenarios for DualUse.
Yeah, with those restrictions, it can be made to work. If you can come up with a good name for the plugin, I can give it a go on ~Wednesday. Should be a reasonably simple endeavour (anyone else is free to beat me to it, mind you!)
I’d name it something like “ToIfAlone” so if someone is coming from Karabiner (like me), they’ll find it right away 
I’ve been thinking about DualUse (or similar) a lot recently, but I haven’t had much time in front of a computer or with pen and paper to work out the details.
I am quite convinced that I want a timer, but only as part of the mechanism, both so that DualUse modifiers can be used to modify mouse clicks and to minimise or eliminate unintended input from overlapping key presses on both ends.
I started with the idea of not including the DualUse key or any subsequently pressed keys in the report until either the DualUse key or the subsequent key is released — if the DualUse key is released first, then include it as a printable character in the next report, then include the subsequent key. If the other key is released first, both get included in the next report, but with the DualUse as a modifier.
That becomes trickier than I originally thought, however, and gets really hairy if the user holds down the DualUse key, then presses and holds more than one other key, too. That in mind, I thought that the decision should be made no later than the second press or release event after the DualUse key is pressed. Anything other than the DualUse key being released would result in the modifier behaviour. Even then, what if there are two keys that get pressed so nearly simultaneously that they both register in the same scan cycle? And what if one of the subsequent keys is itself a DualUse key (that would be a typical use case for my plan, in fact, since the idea is to have one modifier of each type on each finger for ease of chording multiple modifiers)? And there’s also the possibility of overlap with keys pressed before the DualUse key, too.
I suspect that the behaviour I want may actually be possible with timers only, but they’d have to be quite short (maybe 100ms at most), and would also involve some non-trivial overlap detection.
I started trying to take a crack at it…not quite working, but I’ll try to finish it off tomorrow https://github.com/jamesnvc/Kaleidoscope-ToIfAlone
Update: plugin linked above is working! I will update with a README shortly. My first Kaleidoscope plugin
Awesome! Installed and totally working great!!! 
Hooray! Glad to hear it
Time to start filing bugs and feature requests
Please do! Especially bugs, gotta squash those little creatures.