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 bad timestamp initialization in PowerTapDevice showed a lack of
error handling.
This patch makes the DownloadDialog handle bad timestamps more graceful.
Actually it falls back to the current time and allows for later fixing.
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?)
Previous commits turned the status/"Instructions" label into a log. This
allows to show a lot more information that simplify troubleshooting
download issues.
To make it behave a bit more as expected, this change turns the label
into a readonly QTextEdit.
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.
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.
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).
GC supports two download port types: serial ports and D2XX. Before, if
either of these failed to load, the download dialog wouldn't show either
port type. With this patch, if both fail, GC displays a warning, but if
either one succeeds, GC will proceed with only that port type. This
change should fix the problem that users were having to download and
install both the FTDI drivers and the PL2303 ones in order to download
from the SRM PCV.
Hack: SRM PCV download cables use the PL2203 chipset. If the
first device name contains "PL2303", then, we're probably dealing
with an SRM, so go ahead and select the SRM device. Generalize?
I hate to change so many lines of code just for a little rename, but I want to
distinguish between "devices", like the PowerTap and SRM, and "communications
ports", like the serial port and the native D2XX drivers. This work is in
preparation for adding direct download support for the SRM.
