Porting the codebase to QT 5 (5.2) to get the
latest bug fixes, performance and improved platform
support.
This first part is to fixup the codebase to compile
on Qt 5, but some aspects have been broken (video).
The second part is to migrate from Qwt 6.0.1 to the
latest Qwt for multiaxis support.
The third part will be to fixup any platform specific
issues or issues identified at runtime.
fopen() was missing 'b' flag, so that mingw and other platforms doing
LF/CR translation screwed data.
This is fixing the astronomic values of direct SRM downloads.
oops, overwrote the startTime, accidently. Wondering how this passed any
testing as this resulted in all blocks being skipped.
Added explicit initialization of wanted field, aswell.
turned statusCallback into a member of Device (instead of a parameter to
download() and preview(). This allows all methods to access it, directly
and provide better feedback during open/close/erase.
The comm port types supported by srmio may vary depending on the build
system (no ftd2xx.h, no termios, ...).
This commit keeps GoldenCheetah from using unsupported srmio port types
based on the srmio build.
if the devices have a way to identify which CommPort they support and if
CommPorts are just for this device, this is now taken into account for the
port combo box:
Unsupported ports (i.e. currently D2xx for srm) aren't shown for the
selected device type.
Serial ports that are hard-wired to a certain device type (like built in
USB2Serial adapters in PC6/7) aren't offered for other devices, as well.
As a temporary hack, this PCV claims /dev/cu.*PL2303 to be "his". Of
course this has to go, if/when we start supporting other devices with
built in prolific usb2serial adapter or native serial interface (that
might get connected to a prolific adapter).
If we find a way to gather more details for the available ports, we can
extend this quite easily. Possible ideas:
- hald (obsolete)
- libudev (linux specific)
- kdelibs solid (linux specific?)
The new powercontrols have a lot more memory and they allow you to
selectively download the recorded "rides". Looking at srmwin, this seems
to be the suggested way of operation. (i.e. record multiple workouts,
download only the "new" ones).
Furthermore, the SRM file format has some limits (timespan, total number
of records), that make it inapropriate to store "all rides" into one file
and split it later.
So download now
- tries to get a list of rides of the device
- if it gets any, the user can get prompted to choose which to download.
- let device download (selected/all) rides, split if necessary and return
a list with tmp filename, start time, file extension.
- download dialog builds new filename based on time, prompts user for
overwriting when file exists and renames file.
The download Dialog now stays open, so user can read the status messages
and click "cleanup". This avoids many of the anoying message boxes we had
in the Srm download.
Cleanup's user interaction (confirmation, errors) was moved from the
individual device to DownloadDialog, as well.
made srmio handles attributes of the SrmDevice class and added methods to
allocate/open/close/free these handles. So download() + cleanup() can use
the same code.
As a goodie the handles stay open after download and the second
initialization on cleanup() is skipped - saving some time. Well,
assuming the caller reuses the same SrmDevice instance.
SrmDevice destructor takes care of closing/freeing the srmio handles
automagically.
right now there's just one object for each Device type througout the whole
app. This forbids keeping actual state in the Device object during
download/cleanup.
This patch puts the list of supported Devices into a seperate class.
Actual Device objects are now created dynamically.
This is necessary for the upcoming Download changes.
srmio changed it's API completely. Adopted SrmDevice to use new API.
As a first step, we keep using the "simple" API to save everything into a
single file.
While this works fine for PCV, this will run into limitations of the SRM
file format, quite soon. This needs to be addressed in another step.
CommPort::name used to prefix the actual device name/path with the actual
device type to make it unique. This is used in DownloadRideDialog to map
the device dropdown list to the actual device.
This patch seperates name + device type to make the hack in SrmDevice a
bit less ugly: srmio doesn't use the built in CommPort abstraction and
needs the unmodified device names. This is still ugly, but I can't come up
with anything better (... for now).
When you're trying to download data from an empty PCV, srmpc_get_data()
returns a data structure without chunks. This will cause srm_data_write()
to fail.
While SrmDevice is catching errors returned by srmpc_get_data, it doesn't
decode + report what kind of error (errno).
Adjusted message to include the returned error.
Use class wrappers around the srmio library to insure that we always
close every opened device and free all allocated data. Includes other
little bits of stylistic cleanup.
The ghetto part is that we just read the device path out of the device name,
then pass that path directly to Rainer's srmpc_get_data, rather than passing
it an abstraction of a serial port. As such, this code will only work on
Unix-like operating systems. But it does work, and that's a good start.
