Feature request history of input

[Bouh]

Like we can use in Blender add a option for just see the last inputs.

https://www.youtube.com/watch?v=JyDGZW5i4ik

[joao-mambelli]

This can even address the problem with keys being pressed faster than the frame rate of the video/stream, as pointed in #104.

I explain: You could add an element, let's call it History Element, which would have a list of the most recent keys pressed, organized in pressed order, (the maximum amount of elements could just be calculated using the height of the History Element itself with the height of each key event inside it...), this way, even if the frame rate of the video/stream wasn't enough, it would be shown in the History Element.

It's a simple idea that could solve an annoying bug that otherwise would be hard to solve.

And of course, you could add a full list somewhere in the options or saved in a text file just for "proofing"/checking/verification/assertion reasons.

[ThoNohT]

The main issue is that I don't decide what keys are named. That's all in the key definitions. So I either need to give that some default, or let whoever adds this element provide a name for every key that could possibly be pressed.

While the fix I have in mind for #104 could work as a basis for this feature, I don't think I'm going to pick this up just yet.

[joao-mambelli]

So, I tested what you did in #104.

There's still a couple problems:

1. It's still possible to hit a key fast enough that NohBoard won't even detect the event...
2. Imagine you have a macro that will press a certain key every 30 ms, with this new setting set to, let's say 34 ms, which is the required to every key hit to appear in a 30 fps recording, the key will appear to be held, and not spammed...

So, I thought about it a little more, if the History Element will be implemented, it would have to capture both the pressed event and the release event of keys, otherwise you wouldn't know whether you pressed a certain key before or after releasing another key... And also, in the list, each element would need an index written on it, because in a macro situation where you have let's say a single key being spammed, the History Element feed would look the same if no index is shown for each event. So, it would just be a global index variable that would be increased by 1 each time a key event is called...

[ThoNohT]

I'm going to reply to the first 2 points in #104, because they belong there I think. For the rest, I will look at how to implement this when and if I start on that. So I'm not going to look into that now.