This shouldn't happen, but in case there is a logic error higher up in the
code somewhere, this will prevent it from happening, period.
If the code asks for a new dive site with a specific uuid, simply return
the existing dive site with that uuid.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And also show a warning to the user saying that that
action is non-cancelable.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
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>
The way we freed things and cleared out the variables potentially left
dangling data behind and could end up calling free on garbage data,
leading to random crashes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes subsurface crash by simply clicking a dive in the list.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This simplifies the distance calculations and removes a dependency.
This version uses propper math instead of my to simple previous version.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
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>
It's entirely unclear why std::sort sometimes accesses the element with
index -1. In my limited testing switching to qSort avoids that.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
random() is POSIX and seems to be missing in MINGW.
it can return a 64bit (if 'long' is 64bit) but
given ID's are 32bit rand() should suffice.
also random() is technically a better algorithm but for
cryptographically unsafe usage like generating IDs the
stdlib's LCPRNG rand() should siffuce.
also this patch makes it so that a true 32bit random value
is returned. how random it is, is another topic.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
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>
If you want a specific one, you can always overwrite it, but a dive site
with a uuid of 0 breaks some of our assumptions.
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>
