There still some assert left in the code, but removed
a fair number of the examples where, its just as easy
to handle the condition gracefully, without crashing.
By 3.1 we will have eradicated assert from the code.
Slowly migrating code and data from the MainWindow
class to Athlete and Context classes.
This update moves the ride and interval lists and
data structures from MainWindow to Athlete.
Decoupled classes from MainWindow to reference Context
and Athlete (and introduced a couple of new headers).
We no longer pass around a MainWindow pointer to children
but pass a context instead.
There are still a few pieces left in MainWindow that need
to move to a better place;
* Setting/clearing filter selection
* Working with Intervals
* Adding/Deleting Rides
* Save on Exit
As mentioned previously there are lots of other parts to
this refactor left to do;
* break MainWindow Gui elements into Toolbar and Views
* migrate from RideItem and Ridelist to ActivityCollection
and Activity classes that are not tied into gui elements.
* introduce Application Context and AthleteCollection
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.