CoreTemp FIT file read and write

[Ivor Hewitt]

After implementing support for the additional CoreTemp fields (skin temp, heat strain, data quality) adding them into the XData fields I wanted to add support for this into the FIT file reader so it would be possible to import externally generated data for analysis/storage/graphing  (and write out).

I'm not entirely happy with what I've implemented... and I think Mark wasn't either. 😄

PR: https://github.com/GoldenCheetah/GoldenCheetah/pull/4612

1. The CoreTemp values are held as developer fields in the activity record in the FIT file so adding another "decodeXx()" handler in the "switch on record type" doesnt work for these.
The workaround I've implemented here is that when it detects the native "139" value (CoreTemp) it remembers the developer field id, then after the fields have been read in, it calls "decodeCore()" to extract the additional developerfields which don't have native ids to populate the XData. 
2. The second issue is the reverse 🙂 - when populating the FIT file to output I want to use the data from the XData but these don't have a 1to1 relationship with the ride->point arrays so I keep a cursor into the xdatapoints and update it for the matching second as the ride points are iterated through.

Better ideas would be welcome, for 1 the alternative I was considering was to allocate new 'fake' native ids for the developer fields, set the values in the native_num switch and populate the XData beneath.
I couldn't think of a better way for 2. unless I've overlooked a way in the code to ask for the XData related to a ride point.

Cheers

Ivor

[Ale Martinez]

Hi Ivor, I don’t know about 1), wrt 2) in other parts of the code we use https://github.com/GoldenCheetah/GoldenCheetah/blob/95315fd8e7cab6d0be75100b01c3788e1da4b0bf/src/FileIO/RideFile.cpp#L1125 for a similar purpose.

[Ivor Hewitt]

superb! thanks, I hunted and completed missed that. 🤦 I'll rewrite using that and I'll try my alternative for 1 and see how it looks/feels.

In other news... that I've got a working Qt5 video window working with overlays and it *appears* to work smoothly with RLV too. Considerably less of a monstrous hack than it was last night so when it's looking good I'll post a patch up with that, would be interesting to see/check what the performance is like for others.
I'm not running it on particularly fast hardware either (main 'commute' dev machine is an ancient Thinkpad)

Cheers!

Ivor