It never actually triggered anything for me, but any buffered data might
be lost, especially if you force-exit the application after saving a
dive log.
This probably explains a corrupted (truncated) dive file report from
Nathan Samson.
Reported-by: Nathan Samson <https://github.com/nathansamson>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I didn't even notice that the "File" part of the file menu no longer
showed up, since the keyboard accelerator for ^S worked fine.. But
apparently there's no default label associated with GTK_STOCK_FILE in
gtk2, so the "File" text went away with the conversion to GtkUIManager
in commit 4d62478e14 ("Use the newer GtkUIManager for menu creation.")
The addition of a Quit menu entry with the associated keyboard
accelerator also makes ^Q "just work".
Of course, if we actually tracked dirty state etc, we could perhaps ask
the user whether they wanted to save or something. But I'm not exactly
famous for my GUI chops, so ..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's all calculated anyway, and for the same reason we don't bother even
parsing it at load time, we really shouldn't bother saving it either.
The only thing you can do with that value is "check if the percentages
add up to 100%", and so what?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of just tracking gasmix, track the size and workng pressure of
the cylinder too.
And use "cylinder" instead of "tank" throughout.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The computer may track "real" max depth more closely than it tracks
samples. So we trust the non-computed mean/max depths more than the
computed ones.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now the dive profile plot *really* needs some units. The pressure is
just a random line otherwise.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
..since this is now on github, might as well tell people what they need
to compile it, and warn them about the state of the project.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I really don't understand the packing rules. This does not look like
what I intended.
Oh well.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If given multiple dives at the same time, just de-dup the dives. This
happens when you've dumped the whole dive-computer several times, and
some dives show up in multiple dumps.
When de-duping, try to avoid dropping data. So if one dive has notes
attached to it, and the other one does not, pick the notes from the dive
that does have them. Obvious stuff like that.
The sample merge is also written so that it should be possible to merge
two dives. Which we don't actually do yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It looks like the "units.pressure" setting is only about the units that
things are *shown* in on the wrist computer: the units in the file are
always in bar (or rather, centi-bar).
Which is definitely the right thing to do, and means that we shouldn't
care about parsing the units setting. It's purely about how something
is shown, not about parsing.
That's probably true of the other units too, but let's see when I have
more data to go on.
Also, parse water temperatures and tank pressure.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We still end up guessing based on magnitude of the value, though: it
might be 'bar' or 'mbar', we end up picking one or the other based on
just how big the value is.
I should make it look at any possible explicit units too, since at least
with good xml, they exist. Of course, the only good xml I've seen so
far is the one we generate ourselves ;)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I think I'll need to re-organize the handling of per-format code, but
for now we just mix it all up.
The uemis conversion is also questionable even for just the small parts
I do. Does it really do "centiPSI"? That sounds crazy. I'm waiting for
Dirk to send me some actual human-readable output from the dives, right
now some of it is just rough guesses.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If it exists, it really does help identify the dive. At least it does
for me: "local or Maui"?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I think it should be legal xml, but whatever. libxml2 is very unhappy,
and complains when loading - even if I escape them. So let's just
replace the low escape characters with '?'.
The only thing to ever care was my test-case, I suspect.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Let's make it a goal that the XML we output is pretty. That clearly was
never a goal for the Suunto XML, but we can be oh-so-much-better than that.
I still don't love XML, but let's try to make the best of a bad situation,
and take pride in what we do.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use the "empty element" form for samples that don't have any events
associated with them (and none do, right now). This avoids that
annoying "</sample>" crud.
And output the units in the output helpers, so that you can't forget
them even if you try.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When we see a number like 23.145, we'd better always also see a unit.
It's just good practice. So add 'min' to duration (and use only two
digits for number of seconds), and 'm' to depth.
And write the date in international standard format.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The standard way to write a date is yyyy-mm-dd, which is unambiguous and
sorts correctly.
We parsed that right in the 'datetime' case, but not in the normal date
case. And we do want to use that in our output format, exactly because
it's standard.
And also parse 'duration' for the dive duration. It's what we use when
saving, it just so happened that we ended up not parsing it right, but
then picking it up from the samples instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Be more careful with FP conversions, and with the Kelvin<->C offset.
And make sure to use the same names when saving as when parsing.
Now when we save a set of dives, then re-load them, and save again, the
second save image is identical to the first one.
Of course, we don't actually save everything we load, so we still do
lose information when we load and then save the result. But at least we
now don't lose the information that we *do* save.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This just generates another xml file. Don't get me wrong: I still don't
like xml, but this way we can save in the same format we load things
from. Except the save-format is a *lot* cleaner than the abortion that
is Suunto or libdivecomputer xml.
Don't bother with some crazy xml library crap for saving. Just do it!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The only thing you can do with that thing is screw things up (like
libdivecomputer did). There's no value in tracking the "filler" gas,
since you can always just calculate it from the gases that actually
matter.
So just track Oxygen and Helium - and make sure they have sane values.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Did I just say "In comparison, the libdivecomputer output is nice and
sane"?
It turns out that libdivecomputer has been doing some drugs too when it
comes to gas mixes. Like showing O2 percentages as 255.0% and N2
percentages as -155.0%.
Clearly libdivecomputer uses a 'unsigned char' for oxygen percentage,
and makes "-1" be "undefined". And then it prints that non-existing mix
out, and in the process does MATH on the damn thing ("100-O2") to
"calculate" the nitrogen percentage.
Christ.
Just make the parser silently ignore the craziness, because printing out
"Strange percentage reading -155.0" a few hundred times just doesn't
make anything any better.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The suunto xml is just completely crazy. What's the helium percentage
companion to "o2pct"? Would it be "hepct"? No. It's "hepct_0".
Ok, so they didn't number the first o2pct, which could be seen as sane:
that's the only mix value that should always exist. And they clearly
started their indexing with 0. So with multiple mixes, you'd then
expect "o2pct_1" and "hepct_1", right?
Wrong! Because XML people are crazy, the second O2 mix percentage is
obviously "o2pct_2". So the O2 percentages are one-based, with an
implicit one. But the He percentages are zero-based with an explicit
zero. So the second mix is "o2pct_2" and "hepct_1".
I'd like to ask what drugs Suunto people are on, but hey, it's a Finnish
company. No need to ask. Vodka explains everything. LOTS AND LOTS OF
VODKA.
In comparison, the libdivecomputer output is nice and sane, and uses a
'gasmix' node. Of course, now we have so many different XML nesting
nodes to check that I just made it an array of different noces. That
also allows me to mark the suunto case, so that we only do the "check
for crazy alcoholic xml entries" when it's a suunto file.
The "type of file" thing is probably a good idea for deciding on default
units too. Some day.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I'll start doing some kind of "save unparsed things as extended items"
thing, and the ignore rules were just there to get rid of some of the
noise from early parsing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This requires us to change the way we match things up, because now we
can have things like
dives.dive.sample.event.time
and
dives.dive.sample.time
and they are different things (that "sample.event.time" is a 'time'
property of the 'event').
Now, this is always going to be ambiguous, since our linearized name of
the xml doesn't really care whether it's a xml node "child" or a
"property", but quite frankly, I don't care. XML just isn't worth the pain.
In fact, maybe this ambiguity can end up being a good thing. We will
parse these two different lines of XML the same way:
<dive><sample><time>50</time><depth>10.8</depth></sample></dive>
<dive><sample time="50" depth="10.8"></sample></dive>
and the attribute approach seems to be the nicer one. Maybe I'll use
that for the output format.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The executable is now called 'divelog'. If this gets useful enough to
actually *use*, I guess I'll have to come up with a real name some day.
Add a silly README, rename 'parse' to 'parse-xml'.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This tweaks:
- packing to be what you'd kind of expect
- makes the "summary info" always visible
- the "extended info" is now on a notebook page of its own
- dive profile the first notebook page, since the summary
information is visible regardless.
which all just seems a lot more logical.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I'm going to add a menu to import (and eventually export) dives, and so
we'd like to be able to start out with no dives at all. Right now we
croak if that happens - it's not like the code has been written with
actual end users in mind.
So start cleaning things up. First make the 'current_dive' macro work
right even for invalid dives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I dunno. This seems a better interface at least if we get more info for
the dive, but I suspect I'll want to the add basic info to the profile
page too.
This makes the 'table' approach to layout be kind of pointless again,
and the table has become a fancy vbox. Maybe I'll put the core info
back, and use the notebook 'Info' page for extended information.
I should just bite the bullet and start saving the dive data, and adding
editing functions for adding information. But instead I'm playing
around with random gtk widgets.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's still the ugliest application ever, but now it at least gives you
some basic dive info.
I'd love to add a way to edit the dives to add new data (name, buddies,
location etc), but that would also require the ability to save the end
result. Maybe some day.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If we see samples from past the dive duration, update the dive duration.
Likewise with maxdepth.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The time minimum was in seconds, not minutes, and we really do want to
show at least to 90ft to make shallow dives look shallow rather than
scaled to some full depth.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
