Fix "prefer downloaded" dive sample merging case

When we have a preferred dive computer that overrides old information
when merging two dives, we just copy the dive computer data over.
However, we need to clear the source of the dive computer data so that
we then don't free the sample data when that old source of the newly
merged dive gets free'd.

This fixes a memory scribble (and likely SIGSEGV) for the "prefer
downloaded" case.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add basic divecomputer info setup with xml parsing and saving

This also knows how to save and restore multiple dive computers in the
XML data, but there's no way to actually *create* that kind of
information yet (nor do we display it).  Tested by creating fake XML
files with multiple dive computers by hand so far.

The dive computer information right now contains (apart from the sample
and event data that we've always had):

 - the vendor and product name of the dive computer
 - the date of the dive according to the dive computer (so if you change
   the dive date manually, the dive computer date stays around)

Note that if the dive computer date matches the dive date, we won't
bother saving the redundant information in the XML file.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Match newly downloaded dives against dive computer information

Now that we have more complete dive computer information, we can use
that to match the dives we download, and stop with the hacky "Would we
merge this" check.

For XML files without the explicit dive computer information, go back to
checking the exact dive time.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Start merging dives by keeping the dive computer data from both dives

Also, note that we do *not* do the "find_sample_offset()" any more when
we merge two dives that happen at the same time - since we just keep
both sets of dive computer data around.

But we keep the function to find the best offset around, because we may
well want to use it later when *showing* the dive, and trying to match
up the different sample data from the multiple dive computers associated
with the dive.

Because of that, this causes warnings about the now unused function.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Improve on divecomputer data handling

This simplifies the vendor/product fields into just a single "model"
string for the dive computer, since we can't really validly ever use it
any other way anyway.

Also, add 'deviceid' and 'diveid' fields: they are just 32-bit hex
values that are unique for that particular dive computer model.  For
libdivecomputer, they are basically the first word of the SHA1 of the
data that libdivecomputer gives us.

(Trying to expose it in some other way is insane - different dive
computers use different models for the ID, so don't try to do some kind
of serial number or something like that)

For the Uemis Zurich, which doesn't use the libdivecomputer import, we
currently only set the model name.  The computer does have some kind of
device ID string, and we could/should just do the same "SHA1 over the
ID" to give it a unique ID, but the pseudo-xml parsing confuses me, so
I'll let Dirk fix that up.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Do not set the water salinity of a dive unless libdivecomputer supports it

It's annoying to see water salinity data in the XML that isn't relevant,
and adding the default value just because the dive got downloaded from
libdivecomputer is definitely wrong.

We should set the water salinity explicitly only if we have it
explicitly set on the dive computer.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Be much saner about merging dive computer data

Now that we have dive computer device ID fields etc, we can do a much
better job of merging the dive computer data.

The rule is

 - if we actually merge two disjoint dives (ie extended surface interval
   causing the dive computer to think the dive ended and turning two of
   those dives into one), find the *matching* dive computer from the
   other dive to combine with.

 - if we are merging dives at the same time, discard old-style data with
   no dive computer info (ie act like a re-download)

 - if we have new-style dive computers with identifiers, take them all.

which seems to work fairly well.

There's more tweaking to be done, but I think this is getting to the
point where it largely works.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Don't compile unused code to determine offset between samples

Commit bb6b6b49a6d4 "Start merging dives by keeping the dive computer data
from both dives" created a compile time warning. This simply adds an #if /

Yes, this might accelearate bit rod in the code, but I just dislike the
warning message when compiling Subsurface.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fix dive trip selection for merging

When picking the "better" trip, we stupidly looked not at the trip
location, but at the _dive_ location.

Which obviously didn't actually pick the "better" trip information at
all, since it never actually looked at the trip itself.

Oops.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Associate each dive trip with the dives in that trip

We already kept a count of dives per trip in order to figure out when
there are no more dives left and the trip needs to be freed.  Now we
explicitly keep track of the list of dives associated with the trip too,
which simplifies the "find the time of the trip" logic.

We may want to sort it in time, but for now this is mainly about trying
to keep track of the divetrip relationships explicitly.  I want to move
away from the whole "use the gtk tree model to keep track of things"
approach.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Rewrite 'remove_autogen_trips()' without the gtk tree model walking

I'm trying to remove (or at least simplify) the gtk tree model usage for
our trip handling, but I'm doing it in small chunks.  The goal is to
just do all our trip handling logic explicitly using our own data
structures, and use the gtk tree model purely for showing the end
result.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Remove 'when_from_file' field from dive trip

It had become a write-only field (apart from some now useless debugging)
when simplifying the remove_autogen_trips() function.

So remove it.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Clarify (and fix) dive trip auto-generation

This makes the dive trip auto-generation a separate pass from the
showing of the dive trips, which makes things much more understandable.
It simplifies the code a lot too, because it's much more natural to
generate the automatic trip data by walking the dives from oldest to
newest (while the tree model wants to walk the other way).

It gets rid of the most annoying part of using the gtk tree model for
dive trip management, but some still remains.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Handle seconds in decimal notation (from JDiveLog)

This is a hack to convert time stored in decimal notation to proper
seconds. When using metric units the default way of JDiveLog to store
seconds is to have the amount of seconds after decimal point (1.20 is 1
minute 20 seconds). In some odd case it is reportedly possible that the
seconds are actually 100 based, thus we need to convert that to seconds
(1.33333 will become 1 minute 20 seconds).

Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Remove 'tripflag' from dive trips

Both dives and dive trips have the same 'tripflag' thing, but they are
used very differently.  In particular, for dive trips, the only case
that has any meaning is the TF_AUTOGEN case, so instead of having that
trip flag, replace it with a bitfield that says whether the trip was
auto-generated or not.

And make the one-bit bitfields explicitly unsigned.  Signed bitfields
are almost always a mistake, and can be confusing.

Also remove a few now stale macros that are no longer needed now that we
don't do the GList thing for dive list handling, and our autogen logic
has been simplified.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Simplify tripflags: remove tripflag_names[]

This removes the tripflag name array, since it's not actually useful.
The only information we ever save in the XML file is whether a dive is
explicitly not supposed to ever be grouped with a trip ("NOTRIP"), and
everything else is implicit.

I'm going to simplify the trip flags further (possibly removing it
entirely - like I did for dive trips already), and don't like having to
maintain the tripflag_names[] array logic.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fix dive computer event handling if there are no samples

This actually triggers for one of our insane test dives (test15): it has
no samples, so we created a fake dive computer entry with the a fake
profile in it, but we didn't copy the events over.

Having a dive with no samples, yet having events from the dive computer,
sounds pretty bogus.  But that test-case did show that when that bogus
situation happens, we had two independent buglets: (a) we didn't insert
the entries in the fake dive computer entry we used and (b) we would
then mix up the events of the fake dive computer entry with the first
dive computer of a dive.

Fix this, just to make test15 happy again.  And eventually, when we
actually plot the information for multiple dive computers, fixing case
(b) would become necessary even for real dives.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
JDiveLog import fallback for 1 digit numbers

Use the decimal time format fallback also for one digit numbers as
Linus suggested. Thus 1.1 min would result in 1 min 6 sec.

Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Count the actual decimal digits for import

Apply the decimal time conversion hack for JDiveLog import if there are
less than 2 digits in the decimal part (and value is less than 60).

Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Updating events for libdivecomputer 0.3 (and tracking uemis support)

I was a little too eager to add the deco feature to Subsurface. Jef and I
went back and forth a few more times and the definition of those events
changed. I guess I shouldn't have commited that code until the
corresponding libdivecomputer code had been pushed.

This commit now brings us in sync with the current master of
libdivecomputer (but should compile with 0.2 as well - only deco events
won't work then).

One issue that I see is that deco / ndl aren't really a good fit for the
event model. I actually disabled the drawing of the little yellow
triangles for ndl events as for example on the Uemis those events are
created whenever the remaining non stop time changes - and that can be
every few seconds.

The correct solution may be to treat this as a function of the samples,
but for now this works and is tested with both OSTC and Uemis SDA.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>