In this part we have updated all the charts to reference
the RideItem::intervals() members instead of the TreeWidget
and RideFile::intervals().
The code to create/change/delete intervals is not included
so selecting and editing on charts/sidebar is disabled til
part 3 of the update, but hover should work properly.
Still left todo in future updates;
* Updates to the interval sidebar to list intervals
in a tree (by interval type) with a color selector
* Code to create, edit, delete etc the intervals via
the rideitem/intervalitem and see them reflected in
the ridefile
* Update to search for all the different types of
IntervalItems including routes and sustained intervals
.. 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)
... adds "What's this" to (hopefully) most of the widgets (please report
on missing ones)
... defines draft "Whats' this" texts including a
context specific WikiLink
.. Help Key for all platforms is <Shift>+<F1> + in some widgets
"RightMouse - Click"
... Tested on Win and Mac (On Mac QtMacButton seems not supporting
"What's this") - so here <Shift>+<F1> has no result.
... ToDo: Create final texts and links based on the to be updated 3.11
Wiki
.. they are in Athlete::zones() et al now
.. this refactor was missed in the 3.0 mainwindow
refactoring and is part of the prep to use RideItem
as an in memory cache instead of the old metricDB
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.
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
Breaking the MainWindow 'god object' into
separate classes for Athlete and Context.
Further updates will need to;
- 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
Once these are done we will be in a position to decouple
most classes from mainwindow and also introduce tabbed
athletes.
.. added to the splitter handle context menu
.. also took IntervalItem.h and IntervalTreeView.h from MainWindow.h
coz I was getting pissed with recompiling everything when changing it.
Thats why so many other files have been changed in this commit.
Fixes#338.
didn't have enough precision.
Found all (most) of the gps coord to string conversions and used a constant
to insure all conversions occur with the same precision.
Signed-off-by: Greg Lonnon <greg.lonnon@gmail.com>
Following on from the recent changes to the Google Map control
to support their new v3 API, this patch introduces an alternative
map view using the Microsoft Bing v7.0 API.
Remarkably, the MS and Google APIs are extremely similar. Porting the
original code to use the MS API was relatively trivial. It would
probably make sense to combine the two charts into a single chart
with an option to select a map provider.
However, at this point to help in code maintenance they are separate
charts. It is likely that they will diverge somewhat to take advantage
of the differing features offered.
The same functionality and basic colors/lines are available in the
Bing map as the Google one. We should look at adjusting, since the
Bing map styles are more detailed and go to a much higher resolution
than Googles. As a result the current theme looks quite clumsy on
a Bing map and could be changed to use more strident colors and
take advantage of dash polylines (for example).