Updated the user guide to reflect the fact taht the FTDI drivers are
optional for most systems. Changed the instructions for linux install to
reflect that we are now distributing gzipped archives. I also added a in
page link to the wiki.
Fixes#259
When changing the device type in the Download
Ride dilaog the instructions do not change to
reflect the device selected. This patch fixes
that.
Fixes#434.
depending on the style used on a given system the text in the tab bar for
selection of different charts (summary, ride plot...) may be elided on
screens with small resoulution. This overrides the use of scrollbars
which is set explicitly in the code. this one line patch forces the use of
non-elided text in the the tabs so that scroll bars appear.
The header size in FitRideFile has increased from
12 to 14 bytes, but the new field is at the end of
the header, not in the middle.
Additionally, there is a new global record (79) which
we now silently ignore.
Fit file format can now have a 12 and 14 byte header. This
patch adds support for 14 byte headers since this is required
by the latest 310xt firmware.
Fixes#430.
If you attempt to download from a Macro device
and use wrong device or initial read fails then
it crashes, this patch fixes that.
It does not fix more general data errors but should
at least mean incorrect user selections do not result
in GC crashing.
Fixes#366.
The ride import wizard would only allow the user to
change the ride date/time if it was a .gc .json or
.csv file. This was (wrongly) because we could not
update the date/time defined within the ride file itself
(we cannot write in other formats e.g. wko).
Of course, we encode the ride date/time in the filename
and so it could be changed. However, not all the RideFile
readers supported this.
To get around this, the import wizard now does let you
change the date and time for any file type and the ride
file factory method openRideFile() will override whatever
date and time is returned by examining the filename. The
user needs to double click the date or time to edit it.
Additionally, the select date... combo would only register
when you changed the selection, it now defaults back to
the 'select date..' option after each selection.
Lastly, the 'choose date' function now works as advertised
and triggers editing the date for the ride selected.
[commit cd86521 cherry picked into master from release_3.0.0dev]
Fixes#11
Patch to allow v2.1 to read v3.1 .json ridefiles.
Version 3 introduces a new GC file format
using Javascript object notation (json). In
version 3 files are written in this format
as a local, native format thus deprecating the
XML .gc notation.
This backport to 2.1 does not;
* write in json format, it just reads files
* set RideFile::rideId, since it is not present in v2
To build you will need lex/yacc (or flex/bison) the
instructions are within gcconfig.pri.in but are the
same as for version 3.
Fixes#395.
FIT record type '253' occasionally causes time to go
backwards, this might be a decoding error, but for now
we force time to go forward anyway.
Looking at bad files GPS data with this patch suggests
this is the correct behaviour.
Fixes#104.
The LogY function for histograms was overlooked
when implementing intervals. The baseline and
start/end values of the interval curve needed to
be set to non-zero values to match the main curve.
Fixes#396.
When a large number of intervals are defined (>50 or so)
then the RideSummary window crashes.
It appears to be a bug in QTextEdit. It does a double free
when setHtml is called, after a 'large' text item was
set. It may be a QString bug.
To avoid the issue we use a QWebView instead of a QTextEdit
to display the summary and then try and set fonts to match
the application.
[cherry-picked and merged from release_3.0.0dev]
If you save a ride and then delete it. The re-import and save
you will end up with two copies of the ride in the ride list.
This is because when we save the first time the original file
is renamed to e.g. ride.tcx.bak and the new ride.json is then
created. All is well.
But then delete the ride and it will rename ride.json to
ride.json.bak. Again, All is well.
Now, re-import the ride. We now have; ride.tcx.bak and
ride.json.bak and ride.tcx. Again, all is well.
But now, if you make changes and save it will attempt to
rename ride.tcx to ride.tcx.bak AND FAIL. This is because
the old ride.tcx.bak file is there. It will then create
ride.json. All is NOT well, since we have two rides with
the same date and time but different extensions.
This patch fixes this by unlinking ride.ext.bak before
trying to rename the file.
[folded in manually from commit #1d135a in branch release_3.0.0dev]
Some ride file formats use -1 to indicate sensor not
present or data loss (e.g. TPX) and on occasion a NaN
or Infinite value will be presented.
This patch handles this by converting negative data sample
values to zero and handling out of bounds values when
selecting zone ranges.
This is not a substitute for better handling of poor ride
data but it reduces the effect.
Also fixes#311.
The find dialog expected the between values
to be small and high, this patch will find
values between regardless of whether the
search values are lo/hi or hi/lo.
Fixes#351.
The recent patch to allow users to configure which
metrics to display on the ride summary window is not
forwards compatible. If metrics referenced no longer
exist (i.e. they are from a future release or have
been deprecated) GC will crash.
There is no need to warn about seasons.xml missing, it
is quite acceptable to have none set. Worse still sending
to the console log is next to useless for users that
don't launch from the command line.
Partial cherry pick from 4972f2472e (v3.0.0dev)
The WKO+ file format appears to record drops in
recording of GPS data with a latlon of 180,180. We
expect this to be 0,0.
This makes the WKO+ file reader consistent with the
GoogleMapControl and removes the need to clean data
there.
If it is found that 180,180 is the standard way of
recording drops in GPS signal then we can change the
code. We use 0,0 since it is conveniently at sea off
the west coast of Africa.
Cherry pick d06c9e97c9 (From v3.0.0dev)
reading Fit files with Smart recording and a certain pattern of timestamps
could cause assertions. This shouldn't happen, as it's no Programming error.
Changed the checks into graceful failures.
Unfortunatly I don't have any files to test this.
fixes#364
