Input history: Fix #200: add repeat setting; Fix empty space at bottom; Align div instead of padding

[RVillani]

Hi again!

Sorry to bother. I'll be using this for my tutorial videos, so I'm improving it a bit where I believe it would be useful for others too.

Fixed #200

There's now an option to not display a held key repeatedly. It's off by default to keep previous behavior.

Fix space at the bottom

When releasing a key, an empty combination element was added to the history div. Because of that element's margin, a space was added at the bottom, displacing all previous displayed keys up a few pixels. It looked like a glitch.

updateUI()

While making these changes, I streamlined the updateUI() function a bit to control history state in itself, so other functions don't need to know about it.

onKeyEvent() is now smaller, as it just calls updateUI() to both add or remove a pressed key.

This makes _historyCurrentlyPressed be changed in only two places and gives updateUI() control over how to react to key additions whether they're repeated or not. It can also decide when to combine keys, remove or add elements before storing the new _historyCurrentlyPressed state, if needed, and compare to previous states.

These changes might make it easier to add a feature I have in mind: display the number of times a key (or combination) repeated without adding more copies of it. Something like (3) [L CTRL] + [S].

CSS alignment changes

The body div is now aligned to the bottom of html, so history doesn't need forced padding anymore. Also set the icons to display: none, because their div was still taking hidden space.

[univrsal]

Thanks again for the contribution

These changes might make it easier to add a feature I have in mind: display the number of times a key (or combination) repeated without adding more copies of it. Something like (3) [L CTRL] + [S].

Yeah that's something that the old input history source used to have. At some point i might also try and create a preset that is similar to how screenkey works.

[RVillani]

Yeah! I was talking about that too with a friend. But the hard part is to display it both like that and as combinations with modifiers. Because when typing, I see that I type some letters before releasing the previous one. NEXT, for instance, becomes N+E E+X T. So it would have to filter those out while still displaying modifier combinations.

To keep supporting any combination as it is now, I think it would have to support two modes. Let's say "all" and "typing".

I also noticed some commented out masks in a modifiers section in the HTML. If those work, we could use that to make it easier to detect only specific combos for a "typing" mode.

I'm curious to try those out. The count feature and this mode. Because my tutorials involve some coding some times, so that would be useful.

[univrsal]

I also noticed some commented out masks in a modifiers section in the HTML. If those work, we could use that to make it easier to detect only specific combos for a "typing" mode.

The masks for mouse and key events are stored in the "mask" integer in the data variable and you can check for alt, ctrl, shift and meta/windows key via the bits that are in the comment.

The input history source used to only display key combinations or single keys iirc, the code is a mess, but it's still available on the legacy branch.