Get the Qt data structures and convert to something
that we can use in our C - core.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Assume your V2 file contains two locations with different name but
identical GPS location. "Blue Corner" and "Blue Corner, Palau". And you
have many dives there.
When reading a V2 file the GPS is read first and a dive site is looked up
based on that. Let's assume the lookup by gps finds "Blue Corner, Palau".
Now every time we get the "Blue Corner" site in the V2 file we look up
the GPS, get "Blue Corner, Palau" as dive site, then read the name "Blue
Corner" and say "oops, different site" and create a new one. Resulting in
several dive sites named "Blue Corner" with identical GPS but different
UUID (as we add the dive time into the SHA for the deterministic UUID).
With this commit, if we have a dive site that matches the GPS but has a
different name, we check if we happen to have an exact match for the dive
site information from the XML file (and use it, if we have it) before
creating a new dive site.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The UI detects when it should refresh the loction after the
user finished editting a divesite. Creating and editting
divesites is now working even when the current dive is not
saved yet.
Signed-off-by: Sander Kleijwegt <sander@myowndomain.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes it much easier to compare XML files written by Subsurface.
The order of the dive_site_table depended on the order in which they were
encountered. This makes it easier to eye-ball changes in XML files. And
allows the GitStorage test to pass.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Having random uuids seemed like a good idea, but there are several
situations where they really cause problems. One is merging dive file
imports from V2 logfiles. Another is testing such imports.
Instead of making the uuid random we now hash the name and add the
timestamp of the first dive associated with this dive site to the hash
(first in this context is "first encountered" with no guarantee that it is
the chronologically first). This way V2 imports create deterministic uuids
but uuid conflicts are still extremely unlikely, even if the user has
multiple dive sites with the same name.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Test cases require deterministic results and thus we should allow uuid
to be specified when needed.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I'm not convinced that this is useful enough to keep, but let's give it a
try and see what people think.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should ensure that no one ever might end up with our "invalid" name
for real. And it allows us to more easily test elsewhere for that invalid
value.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If both the displayed dive and the dive site which is shown as a potential
completion have a GPS fix, indicate the distance.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we are working on the location management, we want to get a new
dive_site if the dive_site name changed unless there's no dive_site by
that name, then we create it.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And use this to find a dive site within a certain radius of a GPS fix.
This will be used to figure out if dive sites might be the same.
This uses a new Qt5 component (Positioning) which was added in Qt5.2.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fix broken helper function, move helper functions into the .c file (there
really wasn't a good reason for these to be inline), fix the logic that
decides if we want to create a new dive site or use an existing one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While the existing code worked with a couple of hand crafted examples it
turns out it did a poor job with most of my files. Oops.
Depending on whether we find name or coordinates first, we need to
identify existing sites in either case and do the right thing.
The challeng here are multiple dives at the same site with slightly
different GPS coordinates. If the name is read first, these all get merged
into one (and we warn about the different GPS data). But if GPS gets read
first, we create separate dive sites with the same name.
We need a sane UI to consolidate these - but we can't completely automate
this... it's possible that these ARE the same site and the GPS data is
just imprecise (for example, multiple dives at the same time with GPS
locations from the Subsurface companion app). The user should be able to
either pick one of the GPS locations, or keep multiple (for example,
different buoyes for the same site and you want to keep the different
markers).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Sometimes we want to create a dive site just based on a name, sometimes we
have both a name and GPS coordinates. Let's make a helper for either case.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This doesn't make the code necessarily more compact, but easier to read
and is consistent with our other patterns.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
