The intention had been all along to use the 5.4 QSysInfo API, but due to
a silly mistake in the QT_VERSION check, it never got enabled for 5.4.0.
On 5.4.1 it does get enabled and, unfortunately, causes compilation
errors because the API changed between the time we backported to
Subsurface and the final version.
This commit backports the final QSysInfo API from Qt 5.4 into
Subsurface, which includes the renaming of a few functions. Since the
prettyOsName function no longer exists in the Qt API in that form, I've
reimplemented it using the API that does exist.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes prefs.display_unused_tanks also relevant for the planner.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As HTML worldmap export produces wrong HTML in languages that contains
apostrophe in air/water temperature fields like italian. Translated
strings need to be HTML quoted.
Signed-off-by: Gehad elrobey <gehadelrobey@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Null values should be handeled nicely instead of showing NULL or Nan.
Signed-off-by: Gehad elrobey <gehadelrobey@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Don't compare to static english string, must translate first.
Signed-off-by: Gehad elrobey <gehadelrobey@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When reading a pre-v3 XML file, we now do reverse geo lookups on the GPS
coordinates and add the country to the dive site notes. Eventually this
wants to be a tag (once we implement tags for dive sites).
This is going to add quite a bit of delay when people open a V2 XML file -
depending on how many distinct GPS fixes they have. In my case with 127
GPS fixes it took about 20 seconds to open the file...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The conflicting GPS is somewhat artificial. Since the GPS gets parsed
first in our syntax, the different GPS location would create a new dive
site and we'd end up with two dive sites of the same name with different
coordinates. By having a location tag with just the name and no
coordinates we make sure that this gets identified with the existing dive
site and THEN add the GPS coordinates in the second location tag.
This would never happen in a XML file created by Subsurface, but it does a
good job in testing the different code paths.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When reading a v2 XML or git divelog it can happen that we get multiple
names for the same GPS fix or multiple GPS fixes for the same name. We'll
still consolidate them to one entry, but we should not throw away the
conflicting information - instead we should just add this to the notes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is trivial to do with Qt, but when we want to be able to do this in C
code it takes a little more work. This creates a simple pattern to extend
an existing C string.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Adds the ability to undo shifting of dive times. The change is captured
at simplewidgets.cpp and an undo command is created.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the dive site exists, we need to associate the uuid to current dive.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
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>
If we accept a change on the dive site management screen, it needs to be
reflected on the Dive notes tab right away.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user clicks on manage (or double clicks on the globe) and the
displayed_dive doesn't actually have a dive site associated with it (e.g.
because we are adding a dive or because it was imported or downloaded
without dive site information, then we need to make sure that there is an
empty dive site that we can make changes to.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Otherwise there are ugly spaces in the file names. This didn't break
anything, per se, it's mostly cosmetic.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The existing code was bogus as it used cur_dive->dc instead of cur_dc
(i.e., it always changed the first dive computer, even if the po2 was
found in a different one).
But fundamentally I consider this bogus. We are not doing the right thing
here - some dive computer send us pO2 values that are just the calculated
pO2 at a depth and NOT a setpoint, yet we pretend those are setpoints and
then turn these dives into CCR dives.
This needs to done differently.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And hook things up when double clicking the globe.
The user experience isn't consistent with what we do on the main tab
(i.e., no coloring of fields that are changed), but it seems to work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With this all references to these members should be gone and all the code
should be switched over to the dive site infrastructure.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a bit awkward now. We are downloading what looks like fake dives
in the v2 format. So we create a dive site for every single fix.
After we merge those new dive sites into the existing dives we need to
throw away all the dive sites that weren't used.
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>
Since the last few dozen commits change the format in irreversible ways
and could therefore be destructive and lose data for testers of the
development version, let's try to be extra careful and create "special"
backup files that aren't overwritten by subsequent backups. At least this
way people can go back to the previous state.
Of course people using the git backend don't have to worry about this as
they always can go back to any earlier save.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It seems to make sense to only have them on the dive site screen. For the
main UI they were redundant (we have the map) and not all that useful. The
only time people would want them is if they wanted to manually add GPS
coordinates for a dive, but that should now be done via the dive site UI.
There are a couple of FIXMEs in the code and a few code blocks that have
been commented out as they will be needed in one form or another once this
GPS handling is done on the dive site UI, which right now it is NOT.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This simply tracks the names - if we have multiple dives sites with the
same name but different other data (e.g. different GPS), we could easily
get this right (well, somewhat easily, it's a UI question), but for that
we'd have to filter for dive site uuid instead of for dive location name.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
