.. only show them on power plots
.. don't show text
.. make them /really/ faint
NOTE: This is because crank based powermeters (e.g. SRM) will send
calibration messages every time you freewheel for 3 secs or more and
modern headunits (e.g. Nav2Coach) will record and adopt them.
As you can guess, I have an N2C + SRMs and get > 20 or 30 calibrations
every ride with the latest N2C firmware, so this one is for me.
... the .toUTF8() conversion used with QT5.3.x to handle special
characters (e.g. german Umlaute) in column chooser does not work for QT
4.8.6 (at least not for the Windows) - as a result (Drag&Drop from those
fields into Columns or Search Field is not working)
... following the approach other places, changed approach to
"serialization" of the info for "Drag&Drop" - so work independent on any
QT conversions (which seem to depend on other conditions - change over
time)
... second part: 2nd part ("-Layout.XML") translation
... "Mapping Table generation" provided as a new LTMTool routine (to
avoid duplicate code)
... mapping to HomeWindow::restoreState(bool useDefault) for the LTM
Window type charts added
... metricUnit considered in getting the mapping texts for "unit"
... some more tr() (LTMTool, LTMSetting)
... for Lx/Hx in Time and unit "seconds" translation not working in
constructor, therefore moved to "initialization" for both HR and Power
(similar to the translated metric names) (HrTimeInZone, TimeInZone)
... in RC2 - Windows (name with "umlaut") not displayed in official
build (adjusted to be handled like the one name with umlauts already
defined)
.. previously we have computed below cp work as only that
work when power was at or below CP
.. since we want to track energy from CP and W' it makes more
sense to make below CP work include all work not from W' stores.
.. when computing W'bal decay -- since we know the half-life
for the decay we might as well use it rather than a pretty
big constant of 1 hour !
.. it saves about 35% of time to compute metrics
.. we can now drag and move the GProgressDialog around
.. if user hits ESC we trap and ignore it (otherwise it would
triggers a close event that causes a crash)
datacnt is 16bits so it overflows easily for large files (9 hours with
0.5sec recint).
I've also seen datacnt and block sum to be inconsistent in other cases.
To handle this more graceful, we're now taking the max of both counts and
let the EOF detection do it's job when one of them is wrong.
We do have to use one of these limits as some SRM files have junk after
their last chunk (so, just reading chunks till we get EOF retunrs this
junk, too).
code was blindly trusting datacnt... and kept reading past EOF. That's bad
as datacnt occasionally isn't matching the available data (overflow,
corruption, ...)
