For the sequence in your example, the algorithm that I came up with will always give you the correct result (that is, not the modifier), without worrying about how much overlap there is. It only cares about the sequence of events (and the timeout, which is much longer – probably 200-500ms). The only tuning you’d need would be if you were concerned about getting modified clicks with an external pointing device.
(I’m pretty sure using keys for mouse clicks and layer changes will work the same way as typing, but I haven’t tested that or thought it through completely.)
So if your dualUse key down and up is ⇩ and ⇧, and your secondary key ︎ (:downwards_black_arrow:) and ︎ (:upwards_black_arrow:), and nothing has happened to make you sure that ⇩ is a shift, then you should be safe sending:
⇩⬇︎⇧⬆︎ as ⇩⇧⬇︎⬆︎, and leaving ⇩⬇︎⬆︎⇧ alone. My gut says that, for typing at least, you’re only going to have to worry about disambiguating the last two keys; once you’ve got three keys held down together, the first one is definitely a modifier, but I confess I’ve not thought through all the ramifications.
This is great until you’re in a land where latency matters and accuracy of keyDown timings is king. But the only thing I can think of where that matters all that much is gaming, and if you’re serious about that, you’d be advised to have a dedicated gaming layer that does away with pretty much anything that ‘cooks’ the key events in this kind of fashion.
[WTF Unicode? Why do filled arrows work in one place, but not another?]
That’s what I thought until @algernon and @noseglasses both reported that they have data showing instances of four or more keyswitches active simultaneously during normal typing. That’s why I adjusted the algorithm, and defaulted to a limit of eight keys in the queue, since we have only ten fingers, and if we’re using them all, I don’t think that can be called “typing”.
In fact, in your first example, I don’t convert the sequence ⇩,︎,⇧,︎ to ⇩,⇧,︎,︎; it becomes ⇩,︎,[⇧ ︎] (commas separate HID reports from each other). The resulting overlap is dealt with by the host just like it deals with normal overlap from typing on a “dumb” keyboard.
And, yes, this is clearly not intended for gaming. But I did include a way to toggle the whole plugin off (and on).
Indeed. I did set the timeout high enough to confirm things worked as expected, but I’ll need people who can actually type fast to confirm that it really works in practice.
You could try my python scripted Kaleidoscope simulator.
It is not yet released but could neverheless be useful for your testing. It’s supposed to make it much more easy to generate test cases with multiple keys active at the same time.
The README provides info about how to build and run but is still in progress like the whole project.
Build the Python API doc (html) with make doc. It is generated in the doc/kaleidoscope directory of the build tree.
Of course, feel free to contact me if you need any help.
EDIT 1: Updated the name of the module from Kaleidoscope-Python-Wrapper to Kaleidoscope-Python.
I will try it out sometime, thanks! Before I spend much time on that, though, I’ve got two other Kaleidoscope projects that I think are a higher priority: writing doxygen comments in the code, and exploring your plugin interface changes thoroughly. And finishing writing at least the first draft of the repository-management guide for contributors that I started.
︎ (:downwards_black_arrow:) and 
︎ (:upwards_black_arrow:), and nothing has happened to make you sure that ⇩ is a shift, then you should be safe sending:
︎,⇧,
︎ to ⇩,⇧,