Store results and show past scores

[Samyak2]

What and why?

It would be nice if toipe stored the results of each test in a file or a DB on the local system. There could be a screen to display past results - maybe a local leaderboard or a graph tracking speed across time.

How?

TODO. Need to figure out the details.

Context

Suggestion from reddit - https://www.reddit.com/r/rust/comments/tvamfz/comment/i3bqomq/

[abaksy]

Hi, What results specifically would you like to store? The most obvious and easily available metrics are the accuracy and wpm as they're already part of the ToipeResults structure

[Samyak2]

@abaksy perhaps it would be good to store the whole of ToipeResults. Any required metric can then be derived from that.

[grtcdr]

I think CSV should work fine, easily parsable by toipe and is also available to the user for viewing (outside of the program).

[PriceHiller]

I'd be willing to take a crack at this. I just want to know if serialization is something that is open for discussion, or if manual parsing of the values into CSV is preferred.

1. Use Serde and then something like a csv parser that can be used with Serde
2. Make another function under display_results named save_csv and then do the manual conversion in that function.

I'm leaning towards using Serde just because it opens up future expansion for graphing etc. without much, if any, rewriting as most libraries support Serde pretty well. Only issue I know Serde will have is that the started_at and ended_at fields in ToipeResults will have to go because Serde can't serialize std::time::Instant without more external libraries or our own serialization/deserialization implementation. Could just be moved into a single duration: std::time::Duration field and then calculate the Duration before creating the struct.

I'm interested in any thoughts regarding this.

[Samyak2]

@treatybreaker thank you for taking a crack at this. I prefer the serde solution. I'm assuming that each ToipeResults will be serialized individually and appended to the CSV.

Could just be moved into a single duration: std::time::Duration field and then calculate the Duration before creating the struct.

This is reasonable. Although, along with the duration I would also like to store the start timestamp of the test. Perhaps chrono::DateTime.

[argenkiwi]

Is it possible to capture some of the metrics used in keyboard dynamics? I am particularly interested in dwell (or key-hold) time.

Knowing how long I take to press and release a key on average and maximum (or high percentile) would help me adjust some timeouts I need to specify in tools like Kmonad, Kanata and keyd to support home rowm modifiers. I suppose QMK/ZMK users would benefit too.

[Samyak2]

@argenkiwi that's an interesting idea! Do you know any examples of typing test apps that have implemented this? To use as a reference

[argenkiwi]

That's what's odd: there seems to be a lot of content related to keystroke dynamics and keystroke metrics, but the focus is on their use in authentication applications and it seems typing tests focus mostly in WPM and CPM.

I have only been able to find some code snippets on StackOverflow and I made a very simple one myself using Javascript, but it would be ideal if it was processed as part of a typing test because you are incentivized to type with as much accuracy and speed as possible.

[Samyak2]

Thanks for the research!

To know how long a key is pressed, we would need both the key down and key up events. But turns out that detecting key up events in a terminal app is sadly not possible: https://blog.robertelder.org/detect-keyup-event-linux-terminal/

It's possible in web (like you've shown in JS) and desktop apps though.

[argenkiwi]

That is what I feared. Thank you @Samyak2, it helps me narrow down my search.