.. User Metrics now integrated into the factory, ride cache
and of course rides and intervals. Which means you can define
a user metric and it will be computed and displayed like any
of the builtin metrics.
.. lots of technical changes to support this:
* DataFilter gets a runtime object to support multi-threading
and uses a context for construction only - item contexts are
used when evaluating an expression
* RideMetric factory can now remove user metrics
* The context in which the user modifies the user metrics will
notify all other contexts of the change ***
*** NOTE: STRONGLY RECOMMEND THAT YOU DO NOT HAVE MULTIPLE ATHLETES
OPEN WHEN DEVELOPING NEW METRICS SINCE IT WILL TRIGGER A
METRIC REFRESH FOR ALL OPEN ATHLETES.
When the Diary checkbox is set for a metric
"Name: value" is added to Calendar Text.
The "Weight" field is special cased to "Athlete Weight" metric.
Calendar Text is no longer stored in json files, just cached
from Metadata Configuration, Tags and Metrics values.
Fixes#1563
.. RideCache::addRide() deletes the prior ride, which is rather meaningless
if you are just importing a ride, but when syncing large numbers
of rides will stop memory being exhausted.
.. similarly in the FileStoreSyncDialog we now free up the memory
used to read the downloaded files before moving on to the next.
.. was skipping 2p and 3p saves because it was agressively
checking W', FTP and Pmax when they didn't apply or
for values that were possibly correct (e.g. W'/kg > 100)
.. select which kind of intervals we want
.. makes it faster and also reduces the size of
the rideDB.json file quite dramatically which
may be useful for some users.
For single ride use sport specific base metric
For date range use sport specific base metric if filtered activity
list is homogeneous or combined otherwise.
.. Route segments are found during interval refresh
.. Config/routes.xml only holds config now
.. The fingerprint for a rideitem includes the route
fingerprint now so it will refresh automatically
when the routes config changes
.. if no routes are defined then no work is done, so the
amount of work is really defined by the user
NOTE: RouteWindow, and now, RouteItem will need to
be reworked and fixed up for v4.0
.. we are taking a different approach for v3.2
.. the auto discovery will augment rides and maintain a cache
of all intervals across all rides
.. the discovered intervals will be selectable alongside ride
intervals in the sidebar
.. new interval views will be developed in v4.0
... shift plot if start date is earlier than any Power Estimates exist
... enhance grouping (calculation of averages for month/years/all
grouping)
... adjust estimates calculation
... to calculate non-overlapping weeks data
... to not create any "infinite" data for weeks before the first Power
based actitivity exists
.. use a simple free text search against the ridecache now we
have all the texts available and in memory
.. no need to maintain an index, no dependency on a horrid lib
with nasty dependencies and its faster too
.. the free text search is very simple, will need to bolster it
over time e.g. it matches text not words
... for RideImport and RideDownload the created .JSON files are firstly
stored in /tempActivities and only moved to /activities after
successfull updating RideCache (with this files with "bad data" cause
RideCache calculations to crash can be identified when starting GC again
... in GC CrashDialog the /tempActivities are documented in the Crash
Log and moved to /quarantine for further analysis
... small addition - the existence of the new directory structure is
verified when opening an Athlete - missing directories are added to
ensure a consistent structure being in place at all times
.. the "bak" directory was added during the development cycle
and will not be present for users that worked with an early
development build
.. when deleting rides the "bak" rename will fail due to the missing
directory
.. the error message has been changed to provide the details of the
directory where the failure is occurring to help signpost users
to the problem
.. notify if Athlete weight or height were changed by
the user during the config dialog
.. no longer included in zones fingerprint
.. ridecache now picks up on specific config changes
.. when downloading withings data the cache is refreshed
.. when the cache refreshes it notifies the *current* ride
changes if it is refreshed
.. ridesummary has been updated to process rideChanged() signals.
.. to let charts etc know that the *current* ride has
changed and will need to be replotted
.. the editor / dataprocessor functions have also been
integrated into the RideItem to notify the change
.. there is a qDebug() in RideCache in lieu of updating
all the charts to refresh on this signal.
.. introduce concept of configChanged(what) to
pass details of what config has been changed
.. fixed zones changes to re-read after write
to correct the save twice to get changes to
zones bug.
.. next parts need to spot changes (part 2) and
then action appropriately (part 3)
.. rather than check if lucene index contains every ride
upon startup just force a rebuild of the index is missing.
.. if the index gets out of sync its because people are copying
data and so they should delete the index when they do so
to make sure it stays in sync
.. when using '*' for values we autocomplete based upon
previously entered values for the field, but we didn't
take into account ranking.
.. now the autocomplete list is ranked to most popular values
complete first.
.. removes across the code base
.. need to fixup RideFileCache and Lucene refresh
within the RideItem/RideCache framework, they will
NOT be refreshed at present
.. need to look at how charts get refreshed on data
changes now RideItem provides a more granular
mechanism (look for XXXREFRESH in code)
.. New Intervals code will definitely NOT compile
and needs to be redesigned/reimplemented to fit
in with the ride cache
